Aaron Parecki

Got it. I read the link you shared but I must have missed the part about Auth Code flow with no client secret. Sorry.

Regular OAuth 2.0 also supports the Authorization Code flow with no secret. In fact, many companies recommend Auth Code w/no secret instead of Implicit.

IndieAuth is like taking Auth Code w/no secret and adding back some layers of security because of the client ID being a URL.

The link you shared is for Implicit? Implicit does not use client secret. Does this mean IndieAuth is more similar to Implicit than Auth Code but is more secure as the client id has to be redirect uri?

Thanks for this tip!

But, most importantly, the fact that IndieAuth uses a URL for the client ID means that you *do* authenticate the client in the initial Auth Code request, since the redirect URL has to match the domain or be registered. That's an improvement over OAuth with no secret.

Without the secret, there is no authentication of the client. PKCE solves this by using essentially an on-the-fly secret safe for use by mobile apps. IndieAuth *could* adopt the PKCE extension as well, tho afaik noone has done that yet.

Good question! The OAuth Authorization Code flow doesn't require a secret either. For example mobile apps can't use a secret, but still use the Auth Code flow. There are many benefits to the Auth Code flow over Implicit, I wrote some about that here developer.okta.com/blog/2018/05/2…

Does the auth code flow require a client secret? Not sure “less secure” is always true. It is true that the IndieAuth exchange step does not contain proof of the client being the same as from initial request.
It might be an idea to look into tools.ietf.org/html/rfc7636 for that.

Got a #IndieAuth question. Since there is no client pre-registration, there is no client secret. Thus during code/access token exchange no client secret is used. Less secure than Authorization Code and more like Implicit perhaps?