Skip to content

MSC4254: Usage of RFC7009 Token Revocation for Matrix client logout - #4254

Merged
turt2live merged 8 commits into
mainfrom
quenting/oauth2-revocation
Mar 31, 2025
Merged

MSC4254: Usage of RFC7009 Token Revocation for Matrix client logout#4254
turt2live merged 8 commits into
mainfrom
quenting/oauth2-revocation

Conversation

@sandhose

@sandhose sandhose commented Jan 17, 2025 •
edited
Loading

Copy link
Copy Markdown
Member

Rendered

Implemented in matrix-authentication-service, Element X iOS and Android (through the matrix-rust-sdk) and Element Web

Part of the following proposal:

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

I am a Software Engineer at Element. This proposal was written and published as an Element employee.

SCT stuff:

checklist

FCP tickyboxes

@sandhose
sandhose force-pushed the quenting/oauth2-revocation branch from 7780b3b to bc25ec8 Compare January 17, 2025 15:11
@sandhose
sandhose force-pushed the quenting/oauth2-revocation branch from bc25ec8 to ac1602f Compare January 17, 2025 15:12
@sandhose sandhose changed the title MSC4242: Usage of RFC7009 Token Revocation for Matrix client logout MSC4254: Usage of RFC7009 Token Revocation for Matrix client logout Jan 17, 2025
@sandhose
sandhose marked this pull request as ready for review January 17, 2025 15:18
@sandhose sandhose mentioned this pull request Jan 17, 2025
Merged
@turt2live turt2live added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:core MSC which is critical to the protocol's success matrix-2.0 Required for Matrix 2.0 (note: do not rename - used in reports/links) implementation-needs-checking The MSC has an implementation, but the SCT has not yet checked it. Process state. labels Jan 17, 2025
@turt2live turt2live mentioned this pull request Jan 22, 2025
Merged
9 tasks
@turt2live turt2live removed the implementation-needs-checking The MSC has an implementation, but the SCT has not yet checked it. Process state. label Jan 27, 2025
turt2live
turt2live approved these changes Jan 27, 2025
View reviewed changes

@turt2live turt2live left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice and simple: call revoke to revoke

@turt2live

turt2live commented Jan 27, 2025

Copy link
Copy Markdown
Member

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

Checklist:

  • Are appropriate implementation(s)
    specified in the MSC’s PR description?
  • Are all MSCs that this MSC depends on already accepted?
  • For each new endpoint that is introduced:
    • Have authentication requirements been specified?
    • Have rate-limiting requirements been specified?
    • Have guest access requirements been specified?
    • Are error responses specified?
      • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
        • If a new errcode is introduced, is it clear that it is new?
  • Will the MSC require a new room version, and if so, has that been made clear?
    • Is the reason for a new room version clearly stated? For example,
      modifying the set of redacted fields changes how event IDs are calculated,
      thus requiring a new room version.
  • Are backwards-compatibility concerns appropriately addressed?
  • Are the endpoint conventions honoured?
    • Do HTTP endpoints use_underscores_like_this?
    • Will the endpoint return unbounded data? If so, has pagination been considered?
    • If the endpoint utilises pagination, is it consistent with
      the appendices?
  • An introduction exists and clearly outlines the problem being solved.
    Ideally, the first paragraph should be understandable by a non-technical audience.
  • All outstanding threads are resolved
    • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
  • While the exact sections do not need to be present,
    the details implied by the proposal template are covered. Namely:
    • Introduction
    • Proposal text
    • Potential issues
    • Alternatives
    • Dependencies
  • Stable identifiers are used throughout the proposal, except for the unstable prefix section
    • Unstable prefixes consider the awkward accepted-but-not-merged state
    • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
  • Changes have applicable Sign Off from all authors/editors/contributors
  • There is a dedicated "Security Considerations" section which detail
    any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.".
    See RFC3552 for things to think about,
    but in particular pay attention to the OWASP Top Ten.

@turt2live

turt2live commented Jan 27, 2025

Copy link
Copy Markdown
Member

@mscbot fcp merge

@mscbot

mscbot commented Jan 27, 2025 •
edited by KitsuneRal
Loading

Copy link
Copy Markdown
Collaborator

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. disposition-merge Process state. labels Jan 27, 2025
richvdh
richvdh reviewed Feb 11, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
Comment thread proposals/4254-oauth2-revocation.md Outdated
Comment thread proposals/4254-oauth2-revocation.md Outdated
dbkr
dbkr reviewed Feb 11, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
FSG-Cat
FSG-Cat reviewed Feb 12, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
@zecakeh zecakeh mentioned this pull request Feb 17, 2025
Merged
sandhose and others added 3 commits March 5, 2025 16:32
@sandhose
Clarify how the token_type_hint parameter is used
797d26e
@sandhose
Clarify what the server should do if the client_id is not provided
d78fa2a
@sandhose @richvdh @tonkku107
Apply suggestions from code review
9dff517 
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Tonkku <contact@tonkku.me>
@sandhose
sandhose requested review from dbkr and richvdh March 5, 2025 16:36
richvdh
richvdh reviewed Mar 11, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
- `token_type_hint`: This parameter is OPTIONAL, and if present, MUST have a value of either `access_token` or `refresh_token`. The server MAY use this value to optimize the token lookup process
- `client_id`: The client identifier obtained during client registration.

If the `client_id` is not provided, or does not match the client associated with the token, the server SHOULD still revoke the token. The server MAY also warn the user that one of their sessions may be compromised in this scenario.

@richvdh richvdh Mar 11, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely following why a server would want to warn if one of the sessions is compromised if no client_id is provided. A sentence or two of rationale might help here.

@sandhose sandhose Mar 13, 2025

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've explained that better in cd239ce

ara4n
ara4n reviewed Mar 15, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md
2. Support single logout across multiple clients
3. Give visual feedback to the user about the logout process

However, this approach requires a browser redirect which may not be desirable for all clients, especially mobile platforms.

@ara4n ara4n Mar 15, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not following why a browser redirect would ever be a problem (especially on mobile)?

The main proposal made sense when i was reading it, but then on hitting this RP-Initiated Logout alternative, I thought "huh, but these advantages sound great - why aren't we doing this then?", given I don't understand the disadvantage.

@sandhose sandhose Mar 18, 2025

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's relatively unexpected from a user perspective to be bounced through the browser for logging out. This can be relatively transparent for web clients with a redirect, but for native clients, it means opening a browser window, switching context; and there is no defined way to get back to the client after the RP-initiated logout, so you end up outside the client at the end of the logout

@ara4n ara4n Mar 25, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, okay. can you add the rationale to the MSC please? :)

erikjohnston
erikjohnston reviewed Mar 18, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md
Comment thread proposals/4254-oauth2-revocation.md
Comment thread proposals/4254-oauth2-revocation.md
anoadragon453
anoadragon453 approved these changes Mar 25, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
Comment thread proposals/4254-oauth2-revocation.md Outdated
clokep
clokep reviewed Mar 25, 2025
View reviewed changes
Comment thread proposals/4254-oauth2-revocation.md Outdated
Comment thread proposals/4254-oauth2-revocation.md Outdated
@sandhose @clokep
s/login/logout/
047beec 
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
@mscbot

mscbot commented Mar 25, 2025

Copy link
Copy Markdown
Collaborator

🔔 This is now entering its final comment period, as per the review above. 🔔

@mscbot mscbot added final-comment-period Process state to accept, reject, or postpone an MSC. and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. labels Mar 25, 2025
@turt2live turt2live moved this from Ready for FCP ticks to In FCP in Spec Core Team Workflow Mar 26, 2025
@mscbot

mscbot commented Mar 30, 2025

Copy link
Copy Markdown
Collaborator

The final comment period, with a disposition to merge, as per the review above, is now complete.

@mscbot mscbot added finished-final-comment-period FCP has finished. Process state. and removed disposition-merge Process state. final-comment-period Process state to accept, reject, or postpone an MSC. labels Mar 30, 2025
@turt2live
turt2live merged commit 8d2fb67 into main Mar 31, 2025
@turt2live turt2live added spec-pr-missing MSC is accepted, but missing spec PR. Process state. and removed finished-final-comment-period FCP has finished. Process state. labels Mar 31, 2025
@turt2live turt2live moved this from In FCP to Requires spec writing in Spec Core Team Workflow Mar 31, 2025
@NinekoTheCat NinekoTheCat mentioned this pull request Apr 18, 2025
Closed
@zecakeh

zecakeh commented May 25, 2025

Copy link
Copy Markdown
Contributor

spec PR: matrix-org/matrix-spec#2151

@tulir tulir added spec-pr-in-review A proposal which has been PR'd against the spec and is in review and removed spec-pr-missing MSC is accepted, but missing spec PR. Process state. labels May 25, 2025
@turt2live turt2live moved this from Requires spec writing to Requires spec PR review in Spec Core Team Workflow Jun 10, 2025
@richvdh

richvdh commented Jun 20, 2025

Copy link
Copy Markdown
Member

spec PR: matrix-org/matrix-spec#2151

merged! 🎉

@richvdh richvdh added merged A proposal whose PR has merged into the spec! Process state. and removed spec-pr-in-review A proposal which has been PR'd against the spec and is in review labels Jun 20, 2025
@turt2live turt2live moved this from Requires spec PR review to Done to some definition in Spec Core Team Workflow Jun 20, 2025
noelportillo

This comment was marked as spam.

Sign in to view

@krille-chan krille-chan mentioned this pull request Nov 4, 2025
Closed
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@clokep clokep clokep left review comments
@ara4n ara4n ara4n left review comments
@richvdh richvdh richvdh left review comments
@erikjohnston erikjohnston erikjohnston left review comments
@turt2live turt2live turt2live approved these changes
@anoadragon453 anoadragon453 anoadragon453 approved these changes
@dbkr dbkr Awaiting requested review from dbkr
+4 more reviewers
@tonkku107 tonkku107 tonkku107 left review comments
@morguldir morguldir morguldir left review comments
@FSG-Cat FSG-Cat FSG-Cat left review comments
@noelportillo noelportillo noelportillo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

A-Client Server Client-Server API kind:core MSC which is critical to the protocol's success matrix-2.0 Required for Matrix 2.0 (note: do not rename - used in reports/links) merged A proposal whose PR has merged into the spec! Process state. proposal A matrix spec change proposal. Process state.

Projects

Spec Core Team Workflow
Status: Merged/Done

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.