OAuth 2.0 Dynamic Client Registration Compatibility about mastodon HOT 4 OPEN

On an adjacent topic, we've noticed that most apps use a secret-based approach that is not necessarily useful, and instead have seen suggestions to have secret-less apps (the only secrets being the user auth tokens) that would be identified by a an actual deferenceable URL with the expected properties. What do you think of this approach, and how would it play into the OAuth 2.0 Dynamic Client Registration (that I am not familiar with)?

from mastodon.

Yeah, so, even in Dynamic Client Registration, you're still generated a secret, but the assumption is more that you can't keep a secret, so those clients expiry more quickly. If we wanted to reduce the reliance on the secret, we'd probably need to look at DPoP + PKCE where the token is bound to the client.

from mastodon.

The "secretless" that you mentioned @ClearlyClaire may be the "public client" vs "confidential client" concept, which we currently don't support. More on that here: https://auth0.com/docs/get-started/applications/confidential-and-public-applications

So like, for a public client, you would only be able to use Authorization code grant flow with PKCE, and not the other grant flows (e.g., client_credentials). DPoP can be added to further enhance security. When using Authorization Code Flow with Proof Key for Code Exchange (PKCE), no application needs to be registered first, since the client cannot keep anything about the application a secret, doorkeeper does support PKCE.

from mastodon.

Have just discovered that Doorkeeper will seemingly issue a client_secret for a non-confidential client (I don't think it should?), and will allow a client_credentials grant flow for a non-confidential client (it shouldn't per specification, but it's hard to link to the section), and allows passing a client_secret (or not) for authorization_code grant flow for non-confidential clients...

So we may need to look further into exactly how doorkeeper works here.

from mastodon.