OAuth 2.0 Dynamic Client Registration Compatibility

[ThisIsMissEm]

Pitch

At present, Mastodon has an API endpoint for creating OAuth 2.0 applications and getting an client_id / client_secret pair back, which can then be used in OAuth 2.0 flows. This endpoint is POST /api/v1/apps, and whilst it is at a surface level fairly similar to OAuth 2.0 Dynamic Client Registration, there are a number of compatibility issues, as such we cannot advertise this endpoint as the registration_endpoint in the OAuth 2.0 Authorization Server Metadata endpoint (implementation in #29191).

The following is a non-comprehensive list of incompatibilities or differences:

• The mechanism to request specific scopes for your Application is currently scopes instead of scope (https://datatracker.ietf.org/doc/html/rfc7591#section-2 scopes ), and it's possible to currently send an array of scopes which has odd behaviour (POST /api/v1/apps accepts a scopes array but sets scopes to default scopes #30152)
• redirect_uris property currently must be a string, when RFC 7591 expects this to be an Array of string (https://datatracker.ietf.org/doc/html/rfc7591#section-2 redirect_uris) (fixed by Support multiple redirect_uris when creating OAuth 2.0 Applications #29192, but still accepts strings for backwards compatibility)
• No support for client_uri (though we currently have website which is analogous).
• No support for logo_uri, tos_uri, policy_uri or contacts (using these improves the authenticity and trust of applications registered, so supporting them should be recommended)
• No support for software_id and software_version — These can be used to prevent duplicate application registrations and group dynamically registered clients.
• No support for localisation of these properties, e.g., for an english user you may have one tos_uri but for a Spanish language user you might have tos_uri#es which would be displayed to users who are using the Mastodon server in Spanish locale. This can apply to many different fields including client_name.
• No support for "public" clients, only "confidential" clients — this is using token_endpoint_auth_method of none instead of client_secret_post or client_secret_basic, and when creating the Doorkeeper::Application passing confidential: false, though I'm not sure if Doorkeeper actually fully supports public clients (since these don't get certain properties & grant flows)

My suggestion would be to introduce a new endpoint which is compatible with RFC 7591. This may require extensions to Doorkeeper to support various things such as localisation & additional Application properties.

Originally I proposed a POST /api/v2/apps endpoint, but given that this would be implementing the OAuth 2 specific response shapes, I think it'd actually be better as POST /oauth/registration instead, as to indicate that it's not returning a Application nor CredentialApplication entity, but returning what the spec says it should return.

Motivation

By supporting RFC 7591, we'll be able to have standard OAuth 2.0 client libraries interact easily with our services, we also see an end-user benefit by being able to customise the UI during the OAuth 2.0 authorization flow to be localised for the user and to have richer information.

[ClearlyClaire]

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)?

[ThisIsMissEm]

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.

[ThisIsMissEm]

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.