MSC4484: Server Administration OAuth Scope#4484
Conversation
gingershaped
changed the title
gingershaped
force-pushed
the
ginger/msc/admin-oauth-scope
branch
from
e92cbf5 to
699ad98
Compare
There was a problem hiding this comment.
Implementation requirements:
- Server (supporting)
- Client (using)
turt2live
added
T-Feature
| This MSC is explicitly not backwards-compatible. Existing clients using OAuth will no longer be able to use the | ||
| admin API endpoints unless and until they begin requesting the scope. To the best of the author's knowledge, there | ||
| are no clients in widespread use that support OAuth _and_ the Server Administration endpoints, and therefore the | ||
| impact of this change is currently minimal. |
There was a problem hiding this comment.
Doesn't Synapse/MAS already require a special scope for all admin endpoints?
There was a problem hiding this comment.
It does, but I don't know if that scope is only for the Synapse-specific admin endpoints or if it also includes the specced admin endpoints.
There was a problem hiding this comment.
I'd assume it includes the specced ones, but someone should check. If it does, then this potential issue doesn't really exist in the first place (and the MSC may even already be implemented with a different prefix?)
There was a problem hiding this comment.
It appears that it does include the specced ones (logic checking if a user is an admin, call to that logic in the whois endpoint). However, the urn:synapse:admin:* scope also requires the urn:matrix:client:api:* scope, so it doesn't behave the same as the scope described in the proposal.
| ## Proposal | ||
|
|
||
| A new scope is added to the specification, which clients using OAuth MAY request: | ||
| `urn:matrix:client:api:server_administration` (herein referred to as "the scope" for brevity). Clients using OAuth |
There was a problem hiding this comment.
urn:matrix:client:api:* implies it includes everything in that namespace, so if you were to introduce a new scope that is not to be granted by that scope, it should be different at a higher level (like urn:matrix:client:admin or urn:matrix:admin for example).
Worth considering if it should also be defined with a wildcard in the end (e.g. urn:matrix:admin:*) for more fine-grained control in the future like is planned for client-server API
There was a problem hiding this comment.
urn:matrix:client:api:*implies it includes everything in that namespace, so if you were to introduce a new scope that is not to be granted by that scope, it should be different at a higher level (likeurn:matrix:client:adminorurn:matrix:adminfor example).
Good point. I've changed the scope to urn:matrix:client:server_administration.
Worth considering if it should also be defined with a wildcard in the end (e.g.
urn:matrix:admin:*) for more fine-grained control in the future like is planned for client-server API
It seems unlikely to me on the face of it that this will happen -- I would assume that clients generally either want full admin access or no admin access.
4 participants
Rendered
Signed-off-by: Ginger ginger@gingershaped.computer