5 tips to help secure OAuth and OpenID Connect tokens

Safeguarding personal and business information is more crucial than ever as digital technology becomes increasingly prevalent. Identity serves as the primary security boundary for enterprise and consumer applications. As cyberattacks and data breaches continue to rise, protecting sensitive data has become a key priority for individuals and organizations.

According to Verizon’s Data Breach Investigations report (2024), 86% of breaches are attributed to stolen credentials, including passwords, OAuth/OpenID Connect tokens, and API keys. These tokens are typically used to authenticate and authorize users to multiple websites, allow users to stay logged in for an extended period, and retrieve profile information about the user that the website can use to personalize their experience. Applications can use these tokens to access protected resources like APIs and sensitive information.

Securing these privileged artifacts (tokens) has become a mission-critical requirement. What follows are best practices you can implement to secure your OAuth and OpenID Connect tokens.

Quick primer on OAuth/OpenID Connect token and application types

First, let’s go over different OAuth and OpenID Connect token and application types.

Types of tokens

Tokens are secure digital credentials used to verify a user’s identity and grant access to protected resources. The token's payload usually contains information about the user profile, permissions, and metadata, which are cryptographically signed for authenticity and integrity.

ID tokens: As the name indicates, ID tokens are used to identify the principal, (i.e., the end user). They contain information about the user and prove that the OpenID provider has successfully authenticated the user. The audience for this token is the OpenID Client, i.e., the application itself.

Access tokens: OpenID Connect works alongside OAuth 2.0 for authorization purposes. OAuth 2.0 access tokens delegate permissions to the application to call the backend APIs on behalf of the user. The token's audience is the backend API (i.e., the resource server).

Refresh tokens: Access and ID tokens are short lived and expire after a certain period. Refresh tokens are long-lived grants that the application can use to request a new pair of access and ID tokens from the authorization server. The refresh token's audience is the authorization server itself.

Types of applications

According to the OAuth specification, applications can be classified as either confidential or public. The main difference is whether or not the application can securely hold credentials (such as a client ID and secret).

Public applications: These applications cannot securely store client secrets or credentials an authorization server provides. Examples of public applications include modern JavaScript-based client-side applications that run in the browser (single-page applications) and native applications installed on mobile devices and desktops.

Confidential applications: On the other hand, confidential applications can securely store and maintain the confidentiality of client credentials. These applications run on a secure server, and hence, the credentials are not accessible to the end users. Examples of confidential applications include traditional web applications and backend server-to-server applications.

5 best practices to secure your tokens

1. Use asymmetric cryptography for client authentication

Client authentication allows us to verify the identity of the client application to prevent client impersonation and enable secure access to protected resources. Just like passwords are considered a weak user authentication factor, client secrets are a weak client authentication method, as the client secret is contained in the request's body and relies on a shared secret.

Unlike client secrets, asymmetric cryptographic techniques such as mTLS or signed JSON Web Token (JWTs), known as private key JWTs, are never transmitted over the network, dramatically reducing the risk of key leakage and man-in-the-middle attacks. Client authentication applies only to confidential clients. So, while building your application, consider using a robust client authentication method, especially if handling sensitive information. Learn more about client authentication methods.

2. Adopt PKCE for public clients

The rise of mobile and web-based applications has likely led to an increase in public clients. Since client authentication cannot be used with public client applications, Proof Key for Code Exchange (PKCE) ensures that only the original client who initiated the authorization request can exchange the code for tokens.

PKCE ensures that an attacker cannot redeem a stolen authorization code at the authorization server’s token endpoint. While PKCE was initially designed for public clients, OAuth 2.1 recommends PKCE for confidential clients in addition to client authentication, as it offers additional protection against authorization code injection and interception attacks. Learn more about PKCE with authorization code flow.

3. Implement proof of possession

Proof of possession is a method of constraining the use of OAuth access tokens to an authorized client (browser-based app). It can be achieved in two ways: mTLS-based token binding at the transport level or DPoP-based token binding at the application level. Given the scalability, deployability, and usability challenges of mTLS, demonstrating proof of possession (DPoP) is the recommended way to implement proof of possession. DPoP represents a significant improvement in OAuth 2.0 security as it prevents attackers from stealing and replaying tokens. Learn more about OAuth 2.0 DPoP.

4. Consider your token lifecycle management process 

If compromised, long-lived tokens provide a wider window of opportunity for malicious activities that can result in unauthorized access. Therefore, we recommend assigning access tokens short lifetimes and continuously refreshing them as needed.

To mitigate the risks associated with leaked refresh tokens, consider refresh token rotation, which helps to rotate the refresh token securely after every use. Rotating refresh tokens can help detect the reuse of a refresh token, upon which the authorization server can invalidate the refresh token and all the access tokens issued since the user was authenticated. This protects the application from token compromise and replay attacks. Learn more about refresh token rotation.

Revoking all the tokens when a user signs out of an application is also essential. When a token is revoked, it becomes immediately invalid, preventing any further use of that token to access protected resources. Token revocation can happen when the user initiates a logout or when an unexpected event occurs, raising the user's risk profile. With global token revocation, external security and credential providers can request that an authorization server revoke all of a user's existing tokens. This action requires the user to re-authenticate before any new tokens are issued. Learn more about global token revocation and Universal Logout.

5. Apply the principle of least privilege

OAuth/OpenID connect applications should be designed and implemented using the principle of least privilege to enhance the application's security posture and minimize potential risks. Application-specific policies can be leveraged to ensure only the right people can access a specific application from a particular location, device type, risk profile, etc.

OAuth scopes can be used to grant specific permissions in an access token. Scopes should be made as granular as possible to prevent applications from requesting excessive permissions. For use cases that require fine-grained access that changes dynamically, we recommend modeling them off of the OAuth framework. This helps prevent tokens from getting bloated with excessive scopes and claim-related information. Learn more about application sign-on policies, entitlements, and fine-grained authorization.

While this blog highlights some critical aspects of enhancing your token security, the OAuth working group has been developing an exhaustive list of security best practices. Review the official specifications periodically to ensure your applications comply with the latest security trends and Identity standards.

Have questions about this blog post? Reach out to us at [email protected].

Explore more insightful Engineering Blogs from Okta to expand your knowledge.

Ready to join our passionate team of exceptional engineers? Visit our career page.

Unlock the potential of modern and sophisticated Identity management for your organization. Contact Sales for more information.