-
Notifications
You must be signed in to change notification settings - Fork 45
Description
A common mistake when implementing OAuth2 is to assume the refresh token is both generated and used on the same server, and therefore the client secret is always available, and therefore the API requires it.
The OAuth2 RFQ has no requirement for token refresh to require the client secret.
Consider the scenario where a tier 1 server requests and issues the initial OAuth access token and refresh token on behalf of various tier 2 servers. Then the tier 2 servers use their refresh tokens (without the client secret) to refresh their access token. This has multiple benefits:
- Client Secret is secure
- Refresh and Access Tokens must be revoked centrally only
- Delegation of client access to multiple servers using a single application
- Tier 2 servers unable to renegotiate their access without involving the tier 1 server
This architecture is required when you do not know the OAuth redirect uri ahead of time, and therefore cannot register it with the authentication endpoint.
Instead you register the redirect with your tier 1 client server dynamically, and then redirect through the tier 1 server to the tier 2 server, requesting the initial refresh token at the tier 1 server.
This is a perfectly acceptable use-case according to the OAuth2 spec and is useful when distributing client-side software that uses a single OAuth application.