search

blocovermelho / api-rs

0 stars 1 forks source link

Add a flow for servers to request scoped tokens #4

Open alikindsys opened 3 months ago

alikindsys commented 3 months ago

This would be a nice thing to have since it would allow for other servers to use the same login system while blocking modifications to the official api's database.

Scopes

An example of a scope would be user.read and account.read, the first would allow for the server to check if an user exists or not, and the second would allow for a server to verify the password of an existing account, if found.

server.self.update would allow a server to update its own metadata. discord.link.write would allow a server to initiate a discord linking process with the official api's application. account.write would allow a server to create new accounts.

Any official (trusted) servers would be given an token with all scopes, while servers which are administered by members would be given access on a per-need basis, with those servers holding an local database which will not sync with the global source of truth for the functionality they aren't authorized.

The status of each request not being synced with the global source of truth must be notified to the end user, in order to minimize confusion.

Reasoning

This would allow for a wider gamut of possible play styles to be displayed. Ephemeral event servers could also be a part of this.
A team responsible for maintaining the integrations for the required versions of the servers, when enough activity is found would be needed. Carefulness must be taken for this to not be exploited. Session Transferring would be behind a scope, and only allowed between trusted servers which both have the session.transfer scope, and that scope would require session.create and session.destroy scopes.

Re-utilizing the same token in different servers would immediately invalidate the token being used. Two different servers must never have the same token.

Tokens would also expire after a set period and need to be refreshed. Only a single refresh would be allowed per token, and the scopes provided must match exactly the original request.

alikindsys commented 3 months ago

This is blocked behind the migration to sqlite. After that is done and the new system is tested in production we can start handling scopes and a re-structuring of the api permission system.