Skip to content
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

MSC2967: API scopes #2967

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

Conversation

sandhose
Copy link
Member

@sandhose sandhose commented Jan 14, 2021

Rendered

  • Spec is feature complete
    • Device handling
    • Allow for APIs other than Client-Server in the urn:matrix namespace
    • Security considerations section
  • Reviewed for consistency with MSC3861
  • Implementations believed to be complete enough

Dependencies:

Implementations:

Homeservers

Homeservers:

  • Synapse with Matrix Authentication Service in OIDC Playground: https://auth-oidc.element.dev
    • urn:matrix:client:api:*
    • urn:matrix:client:device:XXXX

Clients

Clients need to request scopes appropriately.

  • Element X iOS and Android
    • urn:matrix:client:api:*
    • urn:matrix:client:device:XXXX
  • Element Web
    • urn:matrix:client:api:*
    • urn:matrix:client:device:XXXX
  • hydrogen
    • urn:matrix:client:api:*
    • urn:matrix:client:device:XXXX
  • files-sdk-demo
    • urn:matrix:client:api:*
    • urn:matrix:client:device:XXXX

@turt2live turt2live changed the title MSC2967: [WIP] API scope restriction [WIP] MSC2967: API scope restriction Jan 14, 2021
@turt2live turt2live marked this pull request as draft January 14, 2021 17:28
@turt2live turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Jan 14, 2021
Copy link

@erkinalp erkinalp left a comment

Choose a reason for hiding this comment

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

Don't use the word sudo as we do not have a concept of superusers or substitute users in Matrix.

proposals/2967-api-scopes.md Outdated Show resolved Hide resolved
@aaronraimist
Copy link
Contributor

@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
@hughns hughns changed the title [WIP] MSC2967: API scope restriction [WIP] MSC2967: API scopes Aug 3, 2022
@hughns hughns changed the title [WIP] MSC2967: API scopes [WIP] MSC2967: OIDC API scopes Feb 28, 2023
@turt2live turt2live added the matrix-2.0 Required for Matrix 2.0 label Mar 3, 2023

#### Device ID handling

Presently a device ID is typically generated by the homeserver and is associated with a specific access token. In OAuth 2.0 there is no such thing as a session and so a mapping cannot be handled using the same mechanism.
Copy link
Member

Choose a reason for hiding this comment

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

Is this still true after refresh tokens (MSC2918)? I thought we did a bunch of work in Synapse related to this recently, but maybe I'm confusing different types of tokens.


The Device ID handling involves a change in where device IDs are generated. This is discussed in MSC2964. On the OIDC Provider side the device ID proposal requires the use of dynamic scopes. That is, the specific scope is a templated form rather than being static. This is not currently supported by some OpenID Providers (e.g. Okta and Auth0).

The addition of the `WWW-Authenticate` header could cause issue with some clients.
Copy link
Member

Choose a reason for hiding this comment

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

The header itself or attempting to parse it? We could also provider a matching errcode if that's useful?

Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>

#### Device ID handling

Presently a device ID is typically generated by the homeserver and is associated with a specific access token. In OAuth 2.0 there is no such thing as a session and so a mapping cannot be handled using the same mechanism.

Choose a reason for hiding this comment

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

In OAuth 2.0 there is no such thing as a session and so a mapping cannot be handled using the same mechanism.

In OIDC they define a sid (Session ID) claim within the id_token in the Front-Channel Logout spec (also referenced in other specs)

I would also like to mention that since clients are expected to use dynamic registration, client_ids resemble device IDs quite a bit

@sandhose sandhose changed the base branch from old_master to main September 3, 2024 11:35
- Remove insufficient privilege response
- Remove guest scopes
- Reword some parts
@sandhose sandhose changed the title [WIP] MSC2967: OIDC API scopes MSC2967: OIDC API scopes Sep 16, 2024
@sandhose sandhose marked this pull request as ready for review September 16, 2024 13:11
@sandhose sandhose changed the title MSC2967: OIDC API scopes MSC2967: API scopes Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff matrix-2.0 Required for Matrix 2.0 needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants