-
Notifications
You must be signed in to change notification settings - Fork 385
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
Homeservers as OAuth authorization endpoints (resource owners) (SPEC-206) #531
Comments
Jira watchers: @kegsay |
Also matrix-org/matrix-appservice-gitter#33 could benefit from this most majorly. |
Was this abandoned or superseded by something better? |
neither. we still want this, but nobody has MSC'd it yet. unfortunately kegsay left the project during the funding disruption in 2017, so it hasn't really had a champion since. in other words: it's very much up for grabs! MSCs welcome! |
is this now implemetned by https://matrix.org/docs/spec/client_server/r0.5.0#id199 ? |
OAuth != OpenID, also an OpenID token from a homeserver doesn't give you permission to impersonate that user. |
if this is abandoned, it may as well be closed. |
Documentation: https://docs.google.com/document/d/1vEPFlX79oa1foBmar6i8nvw-hB4SXfVqg6o6Wsdl1kQ/edit
Author: @kegsay
We want third parties (ASes, random web apps which use OAuth to login as someone) to be able to act on behalf of real matrix users. Currently, they simply can't, as they can't authenticate as a given
user_id
.We should probably expose a CS HTTP API endpoint
/oauth
which expects to be hit with aredirect_uri
,scopes
, etc and ideally a browser-sentaccess_token
from the redirect (obviously not automatic given the token is a query param and not aCookie
:( ). If not logged in, you'd need to login as usual for that HS (e.g.m.login.password
) and then go to the "Accept scopes" page. This will then return a token which the 3rd party service can use as anaccess_token
.Note that this is completely different to the role HSes play during reg/login where we ARE the "web app" wanting to authenticate on another 3rd party (FB/G+/etc).
This is becoming increasingly important as more services wish to authenticate as existing user IDs rather than having user ID fragmentation/namespace hell.
(Imported from https://matrix.org/jira/browse/SPEC-206)
(Reported by @kegsay)
The text was updated successfully, but these errors were encountered: