About OAuth Tokens
DoorFlow OAuth authentication uses industry standard best practice
Two tokens are in use at any one time; a refresh token (used to obtain new token pairs); and a short lived access token (used to make API requests).
A simplified version of that standard regarding refresh tokens is here: https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/
The OAuth 2.0 specification encourages short-lived access tokens and long-lived refresh tokens for enhanced security. It doesn't define specific lifetimes for tokens, leaving that to the implementation, but the implication is that shorter is generally better for access tokens.
Some related points often found in OAuth 2.0 and security best practices:
-
Token Compromise: Short-lived access tokens limit the time an attacker can abuse a compromised token. The OAuth 2.0 Threat Model and Security Considerations specifically address the risks associated with token leakage.
-
Least Privilege: Shorter expiration times align with the principle of least privilege, granting only the permissions necessary for the shortest time required.
-
Rotation: Short-lived tokens naturally encourage token rotation, making it harder for attackers to misuse them.
-
Audit and Revoke: With long-lived tokens, it's harder to audit usage and more difficult to revoke them individually without affecting other users.
-
Refresh Tokens: The OAuth spec suggests using refresh tokens to obtain new access tokens. Refresh tokens can be subject to more stringent security measures like client authentication, making it safer to issue short-lived access tokens frequently.
Requesting new tokens
DoorFlow will always issue a new refresh token.
In order to obtain a new access token, a request is made using the refresh token. At this point both tokens are updated and previous tokens invalidated if still active. Both of these tokens should be cached locally within the client application and monitored and updated in order to keep them active.
Remember that a refresh token will only work once.
The expiration time of the refresh token is intentionally never communicated to the client. This is because the client has no actionable steps it can take even if it were able to know when the refresh token would expire. There are also many reasons refresh tokens may expire prior to any expected lifetime of them as well.
Things to watch out for
- Synchronized Token Handling: When a new access and refresh token are received, make sure to atomically replace the old tokens to ensure data integrity. This minimizes the risk of using invalidated tokens.
- Sequential Requests: Avoid making parallel requests to refresh the token. This can lead to race conditions where one operation might invalidate the token being used in another.
- Error Handling: Implement strong error-handling mechanisms for cases where the new tokens are not in the expected format or are otherwise invalid. This should include logging and alerts for manual intervention.
- Timeout Handling: Set reasonable timeouts for your HTTP requests to handle scenarios where a request might hang, allowing for automated retries if needed.
- Validation Before Use: Always validate the new tokens for their format and values before proceeding to replace the old ones. This can prevent issues with malformed or unexpected tokens.
- Retries with Exponential Backoff: If a refresh operation fails, implement a retry mechanism with exponential backoff to ensure you eventually get a valid token, without overwhelming the token server.
- Logs and Monitoring: Keep detailed logs for all operations related to tokens and set up monitoring to alert you of any anomalies or errors immediately.
- Manual Override: Have a mechanism to manually refresh the token in case automated refresh mechanisms fail, but use this only as a last resort.
By incorporating these best practices, they can substantially mitigate the risk of losing a valid access token due to mishandling of the refresh operation.