Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-28 19:48:37 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update Alternatives section

Browse source
This commit is contained in:
Will Hunt 2021-05-05 18:45:33 +01:00 committed by GitHub
parent 0c26298b93
commit 538ac0940e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
proposals/2778-appservice-login.md
View file

@ -67,21 +67,41 @@ new devices should the appservice intentionally or inadvertently have lost the c
## Alternatives
### 1. Include the token in the `/login` request body
One minor tweak to the current proposal could be to include the token as part of the auth data, rather than
being part of the header/params to the request. An argument could be made for either, but since the specification
expects the appservice to pass the token this way in all requests, including `/register`, it seems wise to keep
it that way.
Some community members have used implementation details such as a "shared secret" authentication method to
### 2. Use implementation specific "shared secret" authentication
Some community members have used homeserver implementation details such as a "shared secret" authentication method to
log into the accounts without having to use the /login process at all. Synapse provides such a function,
but also means the appservice can now authenticate as any user on the homeserver. This seems undesirable from a
but also means the appservice can now authenticate as any user on the homeserver. This is undesirable from a
security standpoint.
### 3. Keep using `/register` solely
A third option could be to create a new endpoint that simply creates a new device for an appservice user on demand.
Given the rest of the matrix eco-system does this with /login, and /login is already extensible with `type`, it would
create more work for all parties involved for little benefit.
Finally, `POST /register` does already return a `device_id`, `access_token` for appservice users by default. However critically
Finally, `POST /register` does already return a `device_id` and `access_token` so appservices
could store this information rather than calling `POST /login` at all. This does however present a few problems:
- Quite a few appservices which only support unencrypted messaging do not use/store the `device_id`/`access_token` from a register call.
In the event that an appservice eventually gains the ability to support encryption, they would be unable to fetch a new `device_id`/
`access_token` for any existing users (as `/register` would fail for an existing user).
- If user tokens were lost or exposed, there is no way to programattically create new access tokens for these users.
- Finally, if a user was registered externally and the appservice would like to masquerade as it, it would be unable to fetch
an access token for that user.
While `POST /register` does work, it is impactical as the sole method of fetching an access token.
Most appservices
which do not implement encryption do not store this information as neither the device_id or access_token are needed f However critically
this means that bridges will need to be designed to store the access_token and device_id from the point of creating the user,
so older bridges would be unable to get an access token for existing users as `POST /register` would fail.
It would difficult to log out these tokens if they got exposed additionally, as the AS would not be able to fetch a new access token.