MSC2964: Usage of OAuth 2.0 authorization code grant and refresh token grant

[sandhose]

Rendered

Related: matrix-org/matrix-spec#636

Status:

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

Part of the following proposal:

• MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC #3861

Implementations:

Homeservers

• Synapse implementation with Matrix Authentication Service

Clients

In OIDC-native mode:

• Element Web
• hydrogen
• files-sdk-demo
• Element X iOS
• Element X Android

---

SCT stuff:

checklist

FCP tickyboxes

[sandhose]

Related issue: matrix-org/matrix-spec#636

Related MSCs: #2965, #2966, #2967

---

In this MSC, there are a few areas that still need work.

First, it outlines different profiles of clients. One important client type that is not yet covered by it are CLI tools.
The natural fit for this would be the client credential grant, taking form of either a client_secret or a secret key for JWT signing.
The problem with this is that it authenticates as "the client", not a user. How users should delegate authorization to other clients is a bit unclear. Maybe RFC 8693 helps with that.

Second, there are the parts that we enforce.
For example, I chose to enforce PKCE for public clients. Since most of Matrix clients are public, I think it makes sense to enforce the current best practices here.
Another example would be credentials for confidential clients. Right now nothing is specified, but it might make sense to encourage the usage of keypairs instead of client secrets. If we encourage that, should it be enforced?
Last example, in the part about the request to the authz endpoint, I mention that the state parameter should be unpredictable. Some profiles go further than that to enforce a minimum entropy for this parameter.

Third there is device handling in general. MSC2967 talks a bit about this, but there will definitely be some changes to the device API.
An example of this is that we might want to surface client metadata when querying the devices instead of just an arbitrary name.
Another open question is should a device be deleted on logout? If so, how do we handle device that are used by multiple clients (which is technically possible with the solution proposed in #2967)?

[sandhose]

@turt2live I believe I've now resolved all threads, which should complete the FCP checklist

[anoadragon453]

All non-blocking concerns.

[anoadragon453]

@mscbot resolve FCP checklist incomplete

[mscbot]

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

[mscbot]

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

[zecakeh]

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

[richvdh]

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

merged! 🎉