Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

MSC2965: OAuth 2.0 Authorization Server Metadata discovery #2965

Open
wants to merge 35 commits into
base: main
Choose a base branch
from

Conversation

sandhose
Copy link
Member

@sandhose sandhose commented Jan 14, 2021

Rendered

Status:

  • Spec is feature complete
  • Reviewed for consistency with MSC3861
  • Implementations believed to be complete enough

Dependencies:

Clients and homeservers currently implement an older version of this proposal, and need to be updated:


SCT:

tickyboxes
checklist

@turt2live turt2live changed the title MSC2965: [WIP] OIDC Provider discovery [WIP] MSC2965: OIDC Provider discovery Jan 14, 2021
@turt2live turt2live marked this pull request as draft January 14, 2021 17:27
@turt2live turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Jan 14, 2021
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@erlend-sh
Copy link

erlend-sh commented Aug 9, 2022

Keycloak in OIDC Playground

Are any other examples planned?

I’m using Ory for several apps that I’d like to also connect together with Matrix. It also strikes me as a conveniently lightweight example for Matrix, which also aligns well with Dendrite since it’s in Go.

@hughns
Copy link
Member

hughns commented Aug 14, 2022

@erlend-sh Good suggestion, thank you - I've added element-hq/oidc-playground#3 to track this.

@hughns hughns changed the title [WIP] MSC2965: OIDC Provider discovery MSC2965: OIDC Provider discovery Sep 22, 2022
@hughns hughns marked this pull request as ready for review September 22, 2022 16:08
@turt2live turt2live added the matrix-2.0 Required for Matrix 2.0 label Mar 3, 2023
@turt2live turt2live added kind:core MSC which is critical to the protocol's success implementation-needs-checking The MSC has an implementation, but the SCT has not yet checked it. and removed needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jan 18, 2025
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

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

overall looks good to me - just a few (hopefully) easily correctable concerns

@turt2live
Copy link
Member

turt2live commented Jan 22, 2025

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
Copy link
Member

Implementation lgtm. Concerns are relatively minor as well:

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Jan 22, 2025

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

Concerns:

  • Error codes for not using OIDC
  • Include rationale for Client-Server API endpoint over .well-known
  • Checklist is incomplete

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 final comment period. disposition-merge labels Jan 22, 2025
@turt2live turt2live removed the implementation-needs-checking The MSC has an implementation, but the SCT has not yet checked it. label Jan 22, 2025
@turt2live
Copy link
Member

@mscbot concern Error codes for not using OIDC
@mscbot concern Include rationale for Client-Server API endpoint over .well-known
@mscbot concern Checklist is incomplete

@mscbot mscbot added the unresolved-concerns This proposal has at least one outstanding concern label Jan 22, 2025
@sandhose sandhose requested a review from turt2live January 22, 2025 16:17
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

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

read-up-to marker

(thanks for keeping these updated)

@turt2live
Copy link
Member

@mscbot resolve Error codes for not using OIDC
@mscbot resolve Include rationale for Client-Server API endpoint over .well-known
@mscbot resolve Checklist is incomplete

@mscbot mscbot removed the unresolved-concerns This proposal has at least one outstanding concern label Jan 25, 2025

## Proposal

This introduces a new Client-Server API endpoint to discover the authorization server metadata used by the homeserver.
Copy link
Member

Choose a reason for hiding this comment

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

Can we include a rationale for why we don't hardcode the endpoint URLs to be under a /_matrix/oauth2 scheme? We still need the metdata discovery for other fields, so to an extent there is a question as to "why not", but still.


If the homeserver does not offer next-generation authentication as described in [MSC3861], this endpoint should return a 404 with the `M_UNRECOGNIZED` error code.

In this case, clients should fall back to using the User-Interactive Authentication flows instead to authenticate the user.
Copy link
Member

Choose a reason for hiding this comment

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

or /# ?


In this case, clients should fall back to using the User-Interactive Authentication flows instead to authenticate the user.

## Rationale for not using a `.well-known` document
Copy link
Member

Choose a reason for hiding this comment

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

Editorial nit: put this under the corresponding "Alternatives" entry, rather than making it its own h2 heading?

Copy link
Member

Choose a reason for hiding this comment

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

Yes -- it is really confusing to present this before the alternative of using well-known.

However, the RFC states that an application leveraging this standard should define its own application-specific endpoint, e.g. `/.well-known/matrix-authorization-server`, and _not_ use the `.well-known/oauth-authorization-server` endpoint.
To avoid confusion with the existing `.well-known/matrix/*` documents, this proposal suggests defining a new C-S API endpoint instead.

### Discovery via the well-known client discovery
Copy link
Member

Choose a reason for hiding this comment

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

Nit: it's server discovery rather than client discovery, if anything.

maybe:

Suggested change
### Discovery via the well-known client discovery
### Discovery via existing `.well-known` mechanism

Comment on lines +123 to +126
A previous version of this proposal suggested using the well-known client discovery mechanism to discover the authentication server.
Clients already discover the homeserver when doing a server discovery via the well-known document.

A new `m.authentication` field is added to this document to support OpenID Connect Provider (OP) discovery.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
A previous version of this proposal suggested using the well-known client discovery mechanism to discover the authentication server.
Clients already discover the homeserver when doing a server discovery via the well-known document.
A new `m.authentication` field is added to this document to support OpenID Connect Provider (OP) discovery.
A previous version of this proposal suggested using the existing [homeserver discovery mechanism](https://spec.matrix.org/v1.13/client-server-api/#server-discovery) to discover the authentication server.
A new `m.authentication` field is added to the `.well-known` document to support OpenID Connect Provider (OP) discovery.

The first option would require making well-known documents mandatory on the server name domain, with a document that may need to be updated more frequently than existing ones.
This isn't practical for some server deployments, and clients may find it challenging to consistently perform this discovery.

The second option is also impractical, as all other Matrix APIs on this domain are prefixed with `/_matrix`, and it could easily be confused with the set of well-known documents hosted on the server name domain.
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand this -- I think the thread (https://github.com/matrix-org/matrix-spec-proposals/pull/2965/files#r1924524746) talks about before/after finding the client API. That rationale seems to be missing here.

Frankly to me, I'd expect this to be under well-known.

}
```

**Note**: The fields required for the main flow outlined by [MSC3861] and its sub-proposals are:

Choose a reason for hiding this comment

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

Here we define some required fields for the matrix proposals but I think some clarity is needed on whether requirements from RFC8414 also apply.

bnjbvr pushed a commit to matrix-org/matrix-rust-sdk that referenced this pull request Feb 18, 2025
This is the method to get the server metadata in the latest draft of
[MSC2965](matrix-org/matrix-spec-proposals#2965).

We still keep the old behavior with `GET /auth_issuer` as fallback for
now because it has wider server support.

There are some pre-main commit cleanups to simplify the main commit.
This can be reviewed commit by commit.

The changes were tested with the oidc_cli example on beta.matrix.org.

Closes #4550.

---------

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
disposition-merge kind:core MSC which is critical to the protocol's success matrix-2.0 Required for Matrix 2.0 proposal A matrix spec change proposal proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period.
Projects
Status: Ready for FCP ticks
Development

Successfully merging this pull request may close these issues.