ThisIsMissEm
commented
1 month ago Provided I can secure funding, I'd be able and willing to implement this in Misskey, and also help you team move towards a more standardised OAuth 2.0 implementation, for instance:
- supporting RFC 8414 for Authorization Server Metadata discovery
- supporting PKCE for Authorization Code grant flows
- supporting Issuer Identification for OAuth flows.
Here's how much is changing in the next release of Mastodon relating to OAuth 2.0: https://github.com/mastodon/documentation/pull/1445
kakkokari-gtyih
Summary
As the Misskey team is probably aware, given miauth, OAuth currently requires pre-registration of clients via either an out-of-band process or, in mastodon API verbage, a
POSTto/api/v1/apps. The latter is very similar to OAuth Dynamic Client Registration, which we've realised has some pretty big issues when it comes to federated and decentralised service using OAuth, as such, we've written a new IETF Internet Draft to simplify the process of getting a valid client when performing OAuth authorization code grant flows.Here's the Mastodon ticket for supporting this new internet draft: https://github.com/mastodon/mastodon/issues/31151
https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html
By using this draft, which Mastodon plans to support, Bluesky is implementing and IndieAuth now uses, clients can register automatically with the OAuth Authorization Server (Misskey in this case)
Purpose
This allows you to completely deprecate miauth in favor of OAuth 2.0, whilst still not requiring an explicit application registration before starting the authorization code grant flow.
Do you want to implement this feature yourself?