-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement RFC 8414 for OAuth 2.0 server metadata #29191
Implement RFC 8414 for OAuth 2.0 server metadata #29191
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #29191 +/- ##
=======================================
Coverage 85.01% 85.02%
=======================================
Files 1059 1063 +4
Lines 28277 28349 +72
Branches 4538 4543 +5
=======================================
+ Hits 24040 24103 +63
- Misses 3074 3078 +4
- Partials 1163 1168 +5 ☔ View full report in Codecov by Sentry. |
I think this is now good for review, and hopefully merge in to main for 4.3 (with possibly backporting) |
We generally do not backport features, except if they are motivated by security. |
@renchap I think I can make an argument for that: by advertising scopes available, we encourage third-party developers to negotiate the scopes required, reducing access to data. e.g., currently if I want to access the |
I'm not familiar with RFC 8414, but I'll be looking into it. One question I have is how it interacts with |
I believe you'd want it at the web domain. When we do OAuth Logins, we pass the server's web domain as where to authenticate, so the URLs in here should all be the All the URLs are generated by Doorkeeper, so that should all be using the correct domain. That is to say, in your example, to login with OAuth, a user would need to enter OIDC does have support for webfinger based discovery, but we're using OAuth 2, so we don't yet have a mechanism in webfinger for this. |
56f313e
to
a26efe8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ty
This implements #24099 by doing it directly in Mastodon's codebase, rather than trying to upstream it (upstream were offered and ignored the offer from me to implement it).
I've tried to emulate the code we have elsewhere, and used the Doorkeeper OpenID Connect gem as a reference for some things that are common between RFC 8414 and OpenID Connect specifications.
We could additionally support
ui_locales_supported
, if we have BCP 47 values available for the languages the UI of Mastodon supports (note: we currently don't support localisation of OAuth 2.0 Application names or localised TOS/privacy URLs, as described in RFC 7591 Section 2.2), I'm not sure what the values returned fromLanguagesHelper::SUPPORTED_LOCALES
are and if they are BCP 47 compliant.Example Response:
We use the non-standard
app_registration_endpoint
as that endpoint isn't technically compliant with OAuth 2.0 Dynamic Client Registration. It's similar but not the same.