Document new OAuth changes for 4.3.0 #1445
Conversation
|
I have noticed that there is some churn here due to my editor using Prettier for markdown documents. We may want to consider adopting prettier for this repository. |
ThisIsMissEm
force-pushed
the
chore/document-oauth-changes
branch
from
92be172 to
9e25eff
Compare
|
This pull request has merge conflicts that must be resolved before it can be merged. |
ThisIsMissEm
force-pushed
the
chore/document-oauth-changes
branch
from
7623240 to
83aaf51
Compare
|
Have address majority of the code review comments and left replies where I disagree with said comments or need more information. |
|
This pull request has resolved merge conflicts and is ready for review. |
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
This pull request has resolved merge conflicts and is ready for review. |
…ation used to create them
ThisIsMissEm
force-pushed
the
chore/document-oauth-changes
branch
2 times, most recently
from
26f9c77 to
4c929cf
Compare
| Password grant flow | ||
| : For bots and other single-user applications | ||
|
|
||
| Client credentials flow | ||
| : For applications that do not act on behalf of users | ||
|
|
||
| ### Token revocation endpoint (RFC 7009 Section 2) {#revoke} | ||
| Mastodon has historically supported the Password Grant flow, however, usage is [not recommended](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-resource-owner-password-cre) by the OAuth 2 Specification authors due to security issues, and has subsequently been removed from future versions of Mastodon. Instead, it is recommended that you create an OAuth Application for that user, and use the generated Access Token for interacting with the API. |
There was a problem hiding this comment.
@ClearlyClaire This is the change I did for the removal of the Password Grant Flow Type. Since it's not actually deprecated in 4.3, I've just made it a paragraph explaining it has been supported, but not when it's removed.
|
|
||
| ## OAuth 2 Security Considerations | ||
|
|
||
| ### Proof Key for Code Exchange (PKCE) {#pkce} |
There was a problem hiding this comment.
@ClearlyClaire this is the documentation I've gone with to explain PKCE, I think linking to OAuth.net's documentation around PKCE explains this better than I could here.
There was a problem hiding this comment.
I have separately documented on the oauth/authorize and oauth/token endpoints that we accept the PKCE parameters.
ThisIsMissEm
force-pushed
the
chore/document-oauth-changes
branch
from
4c929cf to
fb058f0
Compare
|
@renchap have rebased this and finished the two remaining tasks. |
|
I took the liberty to commit my two small adjustments, so that we can finally merge. Feel free to open up a follow-up PR if you disagree with my changes. And thanks for all the hard work on this! |
|
@oneiros those changes looked good, I think in the future reworking all this documentation to be more like AT Protocol's OAuth documentation might be a good idea. I think the current tutorial-based documentation leaves a lot to be desired. |
/.well-known/oauth-authorization-serverdocumentation, per Implement RFC 8414 for OAuth 2.0 server metadata mastodon#29191redirect_urionApplicationand addition ofredirect_urisclient_id,client_secret,access_tokenandcodevalues that they should be treated as if they are password, and stored securely.readscope forGET /api/v1/apps/verify_credentials(this now just requires a valid access token), per Feature: Allow oauth application introspection without read scope mastodon#27142client_secret_expires_atonApplication, per Add client_secret_expires_at to OAuth Applications mastodon#30317ApplicationvsCredentialApplicationsplit, per Support multiple redirect_uris when creating OAuth 2.0 Applications mastodon#29192profilescope, per Changeread:mescope toprofilescope mastodon#30357 & Add read:me OAuth 2.0 scope, allowing more limited access to user data mastodon#29087cryptoscope, per: Remove unused E2EE messaging code mastodon#31193This branch is based on #1444