# MSC3824: Ability to distinguish between login and registration
# MSC3824: OIDC aware clients
A client can determine the available authentication methods/types via the `GET /_matrix/client/v3/login` endpoint.
In the context of [MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964) we can define four types of client:
However, unless registration is blanket disabled (i.e. `POST /_matrix/client/v3/register` returns `403`) then it is assumed that both login and registration are possible using all given auth types.
1. *OIDC native client* - This is a client that, where the homeserver supports it, talks to the specified OP in order to complete login and registration. e.g. Element X (WIP), Hydrogen (WIP)
1. *OIDC aware client* - This is a client that is aware of OIDC but will still use existing auth types (e.g. `m.login.sso`) to auth with an OIDC enabled homeserver.
1. *Legacy client with SSO support* - This is a client that is not aware of OIDC but does support `m.login.sso` flow. e.g. Element Web, iOS, Android, Fluffy, Nheko, Cinny
1. *Legacy client without SSO support* - This is a client that is not aware of OIDC at all and nor does it support `m.login.sso` flow. Typically auth is done via `m.login.password` only. e.g. Fractal
Furthermore, a homeserver cannot tell if a `m.login.sso` request for `GET /_matrix/client/v3/login/sso/redirect` is intended to be used to login an existing user or register a new user.
The purpose of differentiating #2 and #3 is that, for a Legacy client with SSO support, the user journey can be optimised with minimal modifications when talking to an OIDC enabled homeserver.
In the context of [MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964):
1. a client needs to know whether registration can be completed by a particular auth type;
2. the homeserver needs to know the intent so that the correct UI can be shown to the user.
This proposal outlines changes to facilitate clients in becoming OIDC aware.
## Proposal
Firstly, the homeserver can optionally specify which actions are supported for an authentication type.
Firstly, a client can specify which action the user is wanting to achieve at the point of SSO redirection. This allows the homeserver to display the most relevant UI to the user.
Secondly, a client can specify which action the user is wanting to achieve at the point of SSO redirection.
Secondly, the homeserver can optionally specify which auth type is `delegated.oidc.compatibility` are supported for an authentication type.
### Homeserver specifies available actions per auth type
### Homeserver indicates that an `m.login.sso` flow is for compatibility
Add an optional `actions` field to the response of `GET /_matrix/client/v3/login`:
Add an optional `delegated.oidc.compatibility` field to the response of `GET /_matrix/client/v3/login`:
`actions?: ("login" | "register")[]`
`"delegated.oidc.compatibility"?: boolean`
For example, if a homeserver supports password for login only, and SSO for login and registration then a response could look like:
For example, if a homeserver is advertising password login for legacy clients only then it could return the following:
```
{
"flows": [{
"type": "m.login.password",
"actions": ["login"],
"type": "m.login.password"
}, {
"type": "m.login.sso",
"actions": ["login", "register"]
"delegated.oidc.compatibility": true
}]
}
```
If no `actions` field is present then the client should assume that both `login` and `register` are both supported unless indicated elsewhere by the API (e.g. registration disabled `403`).
If `actions` is empty array (i.e. `[]`) then no action is supported.
If the client finds `delegated.oidc.compatibility` to be `true` then, assuming it supports that auth type, it should present this as the only login/registration method available to the user.
### Client indicates `action` on SSO redirect
@ -53,15 +50,34 @@ e.g. `https://matrix-client.matrix.org/_matrix/client/v3/login/sso/redirect?acti
n.b. we don't need to add this to the [Login Fallback](https://spec.matrix.org/v1.2/client-server-api/#login-fallback) as that isn't used for registration.
### Definition of OIDC aware
For a client to be considered *OIDC aware* it would:
- support the `m.login.sso` auth flow
- where a `delegated.oidc.compatibility` value of `true` is present on an `m.login.sso` then offer that auth flow to the user
- append `action=login` and `action=register` parameters to the SSO redirect URLs
- sign post and link users to manage their account at the OP web UI given by [MSC2965](https://github.com/matrix-org/matrix-spec-proposals/pull/2965)
For an OIDC enabled homeserver to provide support for *OIDC aware* clients it would:
- support OIDC delegation as per [MSC2964](https://github.com/matrix-org/matrix-spec-proposals/pull/2964) and others
- recommended to advertise the account management UI in accordance with [MSC2965](https://github.com/matrix-org/matrix-spec-proposals/pull/2965)
- provide a compatibility layer for `m.login.password` and `m.login.sso` that wraps on to OIDC
- indicate that the `m.login.sso` is preferred by setting `delegated.oidc.compatibility` to `true`
- make use of the `action` param on the SSO redirect endpoints
## Potential issues
None.
## Alternatives
[Capabilities negotiation](https://spec.matrix.org/v1.2/client-server-api/#capabilities-negotiation) could be used for availability of login vs register.
Clients could assume that an `m.login.sso` is preferred directly from where [MSC2965](https://github.com/matrix-org/matrix-spec-proposals/pull/2965) OP discovery indicates OIDC is being used. However, this might hamper some more custom configuration.
The homeserver could only offer `m.login.sso` as the supported auth type but this would prevent non-SSO capable legacy clients from accessing the homeserver.
Add a `GET /_matrix/client/v3/register` endpoint that would return the available flows for registration. There is an appealing elegance/symmetry to this approach.
[Capabilities negotiation](https://spec.matrix.org/v1.2/client-server-api/#capabilities-negotiation) could be used to indicate that `m.login.sso` is preferred.
For the param on redirect: a `prompt` parameter with values [`create`](https://openid.net/specs/openid-connect-prompt-create-1_0.html#rfc.section.4) and [`login`](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) exists in OIDC for use on the authorized endpoint. However, our use case is different and it might cause confusion to overload these terms.
@ -71,4 +87,14 @@ None relevant.
## Unstable prefix
Not applicable.
While this feature is in development the following unstable prefixes should be used:
Hugh Nimmo-Smith
2 years ago