Convener: Emelia Smith (@thisismissem@hachyderm.io) – not a Mastodon core team member, just a contributor.

Participants who chose to record their names here:

• Jeremiah Lee (@Jeremiah@alpaca.gold)

Tags / links to resources / technology discussed, related to this session:

Documentation PR: https://github.com/mastodon/documentation/pull/1445 with full list of changes.

Notes

Goal: bring Mastodon closer to the OAuth 2.0 specs (there are several).

Jeremiah: Has Mastodon considered adopting GNAP, which solves the dynamic client registration problem?

• Emelia: No, instead looking at OAuth Client ID Metadata Document draft proposal because GNAP is meant to replace OAuth 2 / OIDC and that would mean having to support both protocols to avoid breaking the ecosystem.

GNAP background:

• https://datatracker.ietf.org/wg/gnap/about/
• https://oauth.xyz/
• https://jc1175.medium.com/a-crash-course-in-the-grant-negotiation-and-authorization-protocol-gnap-9cc30ed21ce5
• https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/
• Draft proposal discussed at recent IETF 120 forum in Vancouver and met warmly.
• https://github.com/mastodon/mastodon/issues/31151
• Mastodon team has asked Emelia to implement this, pending funding being worked out.
• Authorization server metadata will say if the server supports this feature.
• Inspired by Solid ODIC client id documents.
• Bluesky has adopted this for their OAuth 2.0 implementation.

We also removed the broken OAuth Application vacuuming, which caused numerous issues for application developers where they’d start an OAuth flow only to discover their application had been deleted from the Mastodon server. This has been replaced with appropriate rate limits on the application registration endpoint. In the future, client_secret values may expire, and these may be advertised via the Application entity (https://github.com/mastodon/mastodon/pull/30317).

Emelia: Also in exploration are Personal Access Tokens (PATs) to supersede self-registered OAuth Application: https://github.com/mastodon/mastodon/issues/31117 — these don’t prevent usage of POST /api/v1/apps but would improve security of use cases where you want an access token for some reason bound to your account. The goal of PATs is to close the security hole where attackers trick everyday non-developer users into use a developer-oriented feature that leads to compromises of their account.

OAuth 2.0 Dynamic Client Registration Compatibility: https://github.com/mastodon/mastodon/issues/30154

• May not be implemented if we do OAuth Client ID Metadata Documents, or if it is, would supersede POST /api/v1/apps.

We’re also exploring public vs confidential clients (currently all clients are treated as confidential meaning they have a client_secret), as well as refresh tokens and shorter-lived access tokens.

• https://github.com/mastodon/mastodon/issues/26838
• Early work: https://github.com/mastodon/mastodon/pull/30329 & https://github.com/mastodon/mastodon/pull/27948

We also introduced a link between Reports created via the API with the OAuth Application used to create them, such that we could identify applications that were consistently filing low-quality reports (e.g., incorrect categorisation, missing comments, missing associated statuses, etc)

Jeremiah: Good to see how many real world use cases driving good refinements of scopes and other features.

Emelia: Yes, much driven from IFTAS work

Tangent discussion on standardizing Mastodon API for client to server. Emelia thinks that’s not a good idea. We need to bring the common features, like requesting your timeline, to an updated client-server standardized spec because the Mastodon API is very specific to it and has many potential “gotchas” if servers just try to immitate the Mastodon API spec.