Pitch
Client ID Metadata Documents is an IETF I-D that myself and @aaronpk have been working on, it's designed specifically for federated & decentralised use cases where you have a many to many relationship between authorization servers and clients.
It is a precursor to being able to support FedCM and IndieAuth (which now references this I-D).
How it works in a nutshell:
- Client starts an Authorization flow with a client_id that is a URI to a JSON document describing the client.
- Authorization Server receives the authorization flow request, and in the pre-authorization stage checks to see if it already has a client for that client_id
- If it does not, it requests that URI in the client_id and creates an OAuth Client (Doorkeeper Application)
- The authorization flow proceeds as normal
No pre-registration with the Authorization Server is necessary.
Motivation
At present, Mastodon's POST /api/v1/apps endpoint is commonly hit multiple times by the same application for different users, since each user needs access to the application to perform an authorization flow.
For SPAs like Phanpy (not calling you out here @cheeaun) this is particularly problematic since the application has no where to store the client details it receives from that endpoint, besides localstorage (insecure), unless they implemented server-side oauth flows with a database to store server -> oauth client details (this is obviously a lot of work and has security considerations)
This results in the Mastodon database being full of essentially duplicate OAuth Applications. For users, this provides bad UX because when they've already authorized a application, but then access it on a new device, they end up with a new application with an access token. This means that when they go to /oauth/authorized_applications in the Settings, they seem multiple copies of the same application, making it really awkward to understand which to revoke. The lack of a "revoke all" option also exacerbates the situation, where users may become unable to spend time revoking all the unique Application Authorizations because they simply have too many of them (I've heard of users having hundred or thousands of Authorized Apps.
Pitch
Client ID Metadata Documents is an IETF I-D that myself and @aaronpk have been working on, it's designed specifically for federated & decentralised use cases where you have a many to many relationship between authorization servers and clients.
It is a precursor to being able to support FedCM and IndieAuth (which now references this I-D).
How it works in a nutshell:
No pre-registration with the Authorization Server is necessary.
Motivation
At present, Mastodon's
POST /api/v1/appsendpoint is commonly hit multiple times by the same application for different users, since each user needs access to the application to perform an authorization flow.For SPAs like Phanpy (not calling you out here @cheeaun) this is particularly problematic since the application has no where to store the client details it receives from that endpoint, besides localstorage (insecure), unless they implemented server-side oauth flows with a database to store server -> oauth client details (this is obviously a lot of work and has security considerations)
This results in the Mastodon database being full of essentially duplicate OAuth Applications. For users, this provides bad UX because when they've already authorized a application, but then access it on a new device, they end up with a new application with an access token. This means that when they go to
/oauth/authorized_applicationsin the Settings, they seem multiple copies of the same application, making it really awkward to understand which to revoke. The lack of a "revoke all" option also exacerbates the situation, where users may become unable to spend time revoking all the unique Application Authorizations because they simply have too many of them (I've heard of users having hundred or thousands of Authorized Apps.