Security Best Practices
Securely storing Client credentials
The Workspace OAuth clients (that you would have created by following the client management guide), especially the client secret in the case of private clients, must be handled like any other secret and stored securely. The method of storing the client credentials might differ depending on your company, however it is strongly advised to use a secret storage management solution that has restricted access.
Do not hardcode the credentials.
If the client credentials are exposed or compromised, we advise to take one of the following actions:
- Perform a client secret rotation and expire the old secret
- Disable the client
- Delete the client and create a new one
For more information on these actions, view the client management guide.
Authorization Flows
To achieve the highest level of security, it is recommended to use the authorization code flow with PKCE as outlined in the authentication guide. This flow is enforced for public clients, but administrators creating private clients can choose whether they wish to use the PKCE flow or the standard authorization code flow without PKCE.
For additional security during the authorization flows, it is mandatory to use the state parameter properly to prevent CSRF (cross-site request forgery) attacks.
User Tokens
User tokens will be issued by the Authorization Server after performing an OAuth Authorization Flow.
Access tokens are the primary tokens that will be consumed by your application; they are considered short-lived and relatively safe to store locally on-device in a secure way. The lifetime of the access token will be provided in the Authorization Server response.
A refresh token will be provided if you have met the requirements (outlined in the client management guide). This is considered a long-lived token, and should not be stored on the client side. Instead, a server-side application can be used to perform the authentication flows and provide the client with an access token, securely storing the refresh token on the server. When the client requires a new access token, the server can then request a new one from the Authorization Server securely. This is demonstrated in our Single Page Application and Native Client open source samples via the Token Management Service.
Access and refresh tokens cannot be revoked. Each time a token refresh flow is performed, the current refresh token is invalidated and cannot be used again. A new refresh token is then returned alongside the access token, as part of a pattern known as ‘Refresh Token Rotation’. As the token is constantly changing with each refresh cycle and the previous is no longer valid, the threat is reduced.