wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #2609 from matrix-org/rav/remove_oauth2

Browse source 
Remove `m.login.token` and `m.login.oauth2` UIA types
This commit is contained in:
Travis Ralston 2020-07-28 10:02:24 -06:00 • committed by GitHub
commit 012f0b1882
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 69 deletions
Download patch file Download diff file Expand all files Collapse all files

1
changelogs/client_server/newsfragments/2609.removal Normal file
View file

@ -0,0 +1 @@
Remove unimplemented ``m.login.oauth2`` and ``m.login.token`` user-interactive authentication mechanisms.

75
specification/client_server_api.rst
View file

@ -433,13 +433,12 @@ User-Interactive Authentication API
Overview
<<<<<<<<
Some API endpoints require authentication that
interacts with the user. The homeserver may provide many different ways of
authenticating, such as user/password auth, login via a social network (OAuth2),
login by confirming a token sent to their email address, etc. This specification
does not define how homeservers should authorise their users but instead
defines the standard interface which implementations should follow so that ANY
client can login to ANY homeserver.
Some API endpoints require authentication that interacts with the user. The
homeserver may provide many different ways of authenticating, such as
user/password auth, login via a single-sign-on server (SSO), etc. This
specification does not define how homeservers should authorise their users but
instead defines the standard interface which implementations should follow so
that ANY client can login to ANY homeserver.
The process takes the form of one or more 'stages'. At each stage the client
submits a set of data for a given authentication type and awaits a response
@ -665,11 +664,9 @@ Authentication types
This specification defines the following auth types:
- ``m.login.password``
- ``m.login.recaptcha``
- ``m.login.oauth2``
- ``m.login.sso``
- ``m.login.email.identity``
- ``m.login.msisdn``
- ``m.login.token``
- ``m.login.dummy``
Password-based
@ -746,66 +743,6 @@ To use this authentication type, clients should submit an auth dict as follows:
"session": "<session ID>"
}
Token-based
<<<<<<<<<<<
:Type:
``m.login.token``
:Description:
The client submits a login token.
To use this authentication type, clients should submit an auth dict as follows:
.. code:: json
{
"type": "m.login.token",
"token": "<token>",
"txn_id": "<client generated nonce>",
"session": "<session ID>"
}
A client may receive a login ``token`` via some external service, such as email
or SMS. Note that a login token is separate from an access token, the latter
providing general authentication to various API endpoints.
Additionally, the server must encode the user ID in the ``token``; there is
therefore no need for the client to submit a separate username.
The ``txn_id`` should be a random string generated by the client for the
request. The same ``txn_id`` should be used if retrying the request. The
``txn_id`` may be used by the server to disallow other devices from using the
token, thus providing "single use" tokens while still allowing the device to
retry the request. This would be done by tying the token to the ``txn_id``
server side, as well as potentially invalidating the token completely once the
device has successfully logged in (e.g. when we receive a request from the
newly provisioned access_token).
OAuth2-based
<<<<<<<<<<<<
:Type:
``m.login.oauth2``
:Description:
Authentication is supported via OAuth2 URLs. This login consists of multiple
requests.
:Parameters:
``uri``: Authorization Request URI OR service selection URI. Both contain an
encoded ``redirect URI``.
The homeserver acts as a 'confidential' client for the purposes of OAuth2. If
the uri is a ``service selection URI``, it MUST point to a webpage which prompts
the user to choose which service to authorize with. On selection of a service,
this MUST link through to an ``Authorization Request URI``. If there is only one
service which the homeserver accepts when logging in, this indirection can be
skipped and the "uri" key can be the ``Authorization Request URI``.
The client then visits the ``Authorization Request URI``, which then shows the
OAuth2 Allow/Deny prompt. Hitting 'Allow' redirects to the ``redirect URI`` with
the auth code. Homeservers can choose any path for the ``redirect URI``. Once
the OAuth flow has completed, the client retries the request with the session
only, as above.
Single Sign-On
<<<<<<<<<<<<<<
:Type: