Skip to content
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

Add a flow for servers to request scoped tokens #4

Open
alikindsys opened this issue Jun 27, 2024 · 1 comment
Open

Add a flow for servers to request scoped tokens #4

alikindsys opened this issue Jun 27, 2024 · 1 comment

Comments

@alikindsys
Copy link
Contributor

alikindsys commented Jun 27, 2024

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant