Closed MartinKolarik closed 1 month ago
Since there will be a lot of such anon tokens, I think they should be purged after expiration. Purging may also be applied to other expired token, but with some delay.
I thought about deleting expiring tokens in general as well but these tokens in particular shouldn't really expire. The refresh tokens are going to have long expiration, probably 1 year, and the old access tokens are already being revoked by the oauth server during the refresh token grant.
I thought about deleting expiring tokens in general as well but these tokens in particular shouldn't really expire.
Client credentials tokens are exiping in 24h right now.
The refresh tokens are going to have long expiration, probably 1 year, and the old access tokens are already being revoked by the oauth server during the refresh token grant.
You're checking an access token most likely.
Yes, but Client Credentials doesn't return refresh token.
You're right, in that case, using a custom grant type seems like the best solution. We should be able to add something like globalping_client_credentials
which works similarly but returns both tokens: https://node-oauthoauth2-server.readthedocs.io/en/master/misc/extension-grants.html
Problem
The Slack app and GitHub bot send requests for all users from the same IP, which means they all share the rate limit when not logged in. We need each user to have their own unauthenticated limit.
Solution
The API is updated to handle tokens without a user ID. For these tokens, the hashed token value is used as the rate limiter key. The Directus schema already allows tokens without a user. Our apps will use Client Credentials Grant (not allowed for other apps) via the auth server to obtain a separate token for each Slack workspace (might require small changes + tests in the auth repo).