OAuth 2.0 security best current practices
Introduction
OAuth 2.0 is a widely used protocol for delegated authorization, enabling users to grant controlled access to their resources without sharing their credentials. However, ensuring secure implementation of OAuth 2.0 requires careful consideration of security topics and best practices. The OAuth 2.0 Security Best Current Practice provides valuable insights and recommendations for secure OAuth 2.0 implementations.
At Safewhere, we are committed to follow the guidelines outlined in the OAuth 2.0 Security Best Current Practice document. In this topic, we will explore how Safewhere Identify aligns with these recommendations. Additionally, we will provide guidance on how applications can effectively adhere to these best practices when utilizing Safewhere Identify as their Authorization Server.
Best practices
Protecting redirect-based flows
Safewhere Identify restricts redirect-based flows to only allow redirection to URIs registered within the application to safeguard against potential vulnerabilities. This measure ensures that unauthorized redirection attempts are thwarted. Identifying exact matches in URIs, Safewhere Identify excludes URIs with wildcards from the redirection process.
To further fortify protection against CSRF attacks, client applications can leverage Safewhere Identify's full support for PKCE and the nonce parameter. These mechanisms provide robust defense against CSRF exploits, enhancing the overall security posture of the application.
Authorization code grant
Safewhere Identify supports PKCE and nonce parameters to enhance security during authorization code grant flows. Client applications must adhere to the recommendations outlined in the OAuth 2.0 Security Best Current Practice document to mitigate authorization code injection attacks and misuse of authorization codes.
Alternatively, confidential OpenID Connect clients may utilize the nonce parameter and the corresponding claim in the ID Token, with additional precautions outlined in the specification. Regardless of the chosen method, the PKCE challenge or OpenID Connect nonce must be transaction-specific and securely bound to the client and user agent.
Clients should employ PKCE code challenge methods that do not expose the PKCE verifier in the authorization request to ensure maximum security. Safewhere Identify follows the specification by supporting PKCE and enforcing correct usage of code_verifier at the token endpoint. Authorization servers must also support PKCE [RFC7636] and mitigate PKCE Downgrade Attacks by validating the presence of code_challenge parameters in token requests.
Implicit grant
The Implicit Grant and similar methods expose access tokens in URLs, making them vulnerable to leakage and replay attacks. Without sender-constrained tokens, stolen tokens can be misused by attackers.
Instead, use the Authorization Code Flow with PKCE. This approach hides access tokens, prevents replay attacks, and adds a cryptographic challenge for extra security. OAuth 2.1 removes the Implicit Grant due to these risks, so switching to PKCE is the safest choice.
Token replay prevention
Access tokens
Using sender-constrained access tokens enhances security by limiting the applicability of an access token to a specific sender. This sender must demonstrate knowledge of a particular secret to ensure acceptance of the token at the recipient, such as a resource server.
Authorization and resource servers are encouraged to implement mechanisms for sender-constraining access tokens. One such mechanism is Mutual TLS for OAuth 2.0 (RFC8705), which establishes a secure channel between the client and server to prevent misuse of stolen or leaked access tokens. For further details and implementation guidelines, refer to the OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens documentation.
Refresh tokens
It is recommended to use token rotation for refresh tokens, especially for public clients to enhance security. Token rotation ensures that refresh tokens are regularly rotated, reducing the window of opportunity for attackers in case of token theft.
Additionally, refresh tokens for public clients should be sender-constrained, meaning they are bound to a specific sender. This prevents unauthorized use of refresh tokens even if they are intercepted by attackers. You can configure token rotation settings in the administration interface of your OAuth authorization server. Below is a screenshot demonstrating where to access these settings:
Access token privilege restriction
Access tokens should be restricted to specific resource servers or a small set of resource servers to enhance security. This restriction ensures that each access token is only valid for accessing designated resources, reducing the risk of unauthorized access.
In Safewhere Identify version 5.17 and above, new features related to audience and resource server have been implemented to facilitate access token privilege restriction. You can configure these settings in the administration interface of your OAuth authorization server.
Audience restriction: Configure the audience setting to specify the intended audience for each access token. This ensures that the access token is only accepted by the designated resource server(s).
Resource server configuration: The Identify Admin has a fine-grained authorization system that empowers administrators with granular control over user privileges and access rights. For further details, refer to the Identify Admin's fine-grained authorization.
Resource owner password credentials grant
The Resource Owner Password Credentials grant is insecure and should be avoided. It exposes user passwords to the client app, increasing the risk of credential leaks and bad security habits. It also does not support modern authentication methods like two-factor authentication (2FA) or strong cryptographic credentials. OAuth 2.1 removes this grant due to these risks.
Instead, use safer alternatives like the Authorization Code Flow with PKCE, which ensures better security and compatibility with modern authentication.
Client authentication
Authorization servers should enforce client authentication whenever feasible. This involves establishing a process for issuing and registering credentials for clients, while ensuring the confidentiality of these credentials. For enhanced security, it is recommended to utilize asymmetric cryptography methods for client authentication. This includes options such as Mutual TLS (mTLS) or signed JSON Web Tokens (JWTs), also known as "Private Key JWT."
When asymmetric cryptography is employed for client authentication, authorization servers do not need to store sensitive symmetric keys. This enhances security by reducing the risk of key leakage and ensuring the robustness of the authentication process.
For further details and implementation guidelines, refer to the OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens documentation.
Other recommendations
In alignment with best practices outlined in OAuth 2.0 Security Best Current Practice, Identify incorporates the following security measures:
- Metadata: Identify provides comprehensive metadata support, enabling clients to obtain relevant information about endpoints, supported algorithms, and other critical details.
- Client Registration: Client applications are required to be registered via the Admin interface to ensure proper management of client credentials. While dynamic registration is available, it is not recommended due to security implications.
- HTTPS Usage: Identify mandates the use of HTTPS by default to encrypt communication between clients and servers, safeguarding sensitive information from potential eavesdropping or tampering.
- CORS Policy: The authorize endpoint strictly prohibits Cross-Origin Resource Sharing (CORS) to mitigate risks associated with unauthorized access. However, specific endpoints, such as the OIDC discovery endpoint
https://#identify_instance_domain#/runtime/oauth2/.well-known/openid-configuration, the certificates endpointhttps://#identify_instance_domain#/runtime/oauth2/certs.idp, and thehttps://#identify_instance_domain#/runtime/oauth2/userinfo.idpendpoint, are configured to allow CORS for designated purposes, enhancing flexibility while maintaining security standards.
Attacks and Mitigations
Safewhere Identify OAuth 2.0 Server mitigates all common critical threats in the OAuth 2.0 Security Best Current Practice document. Here’s a breakdown of the technical implementations:
Access token leakage via browser
Identify OAuth 2.0 Server does not store tokens in browser's local storage or cookies.
Access token leakage via referrer header
Referrer-Policy headers are set to no-referrer on pages with sensitive data, ensuring that tokens aren’t exposed in requests to other domains.
Authorization code interception
Identify supports PKCE (Proof Key for Code Exchange) to enforces client validation. Only HTTPS requests are accepted, and TLS encryption is strictly enforced for secure transmission.
Authorization code injection
CSRF Tokens and unique authorization states ensure that the received authorization code is legitimate. Each authorization request generates a unique, single-use session token.
Redirect URI manipulation
Identify OAuth 2.0 server strictly enforces redirect URI validation by checking that the redirect URI matches exactly with the one registered. Variations or unregistered URIs are rejected.
Access token replay attack
Both refresh and access token expiration times are configurable so that Admin can set them short enough for this kind of security. Tokens are signed and validated using HMAC or RSA signatures.
Access token leakage via Cross-Site Scripting (XSS)
All scripts are controlled through CSP headers. Only HttpOnly cookies are used for tokens, preventing JavaScript from accessing token values.
Cross-Site Request Forgery (CSRF)
OAuth 2.0 is generally safe from CSRF: state parameter to prevent CSRF attacks during the authorization flow, PKCE to prevents token interception.
Malicious redirect URI
Identify OAuth server validates and logs every redirect URI request, validate it against registered values. Each URI is manually approved to prevent redirection to untrusted locations.
Authorization code reuse
Authorization codes are limited to a single use. Our server logs and invalidates any code after the first valid exchange, preventing reuse.
Weak token expiry management
Tokens are short-lived and can be renewed only with a valid refresh token. Expired tokens are purged by our backend regularly to reduce the risk of replay attacks.
Clickjacking
By default, our server implements X-Frame-Options: SAMEORIGIN and Content-Security-Policy: frame-ancestors 'self' headers to prevent framing on external sites.
Lack of secure storage for secrets
Tokens, secret codes, and session information are encrypted with the Data Protection API using newest encryption algorithm, ensuring data security at rest.
These measures align with the latest best practices for OAuth 2.0, helping Safewhere Identify OAuth 2.0 server maintain high standards for user data protection and access control.
Conclusion
Securing OAuth 2.0 is crucial to protecting user data and ensuring safe authorization. Safewhere Identify follows the best security practices, using features like PKCE, sender-constrained tokens, and strong client authentication to prevent threats.
Developers and administrators should follow these guidelines and leverage the security features offered by Safewhere Identify to build secure and reliable applications. For further details and implementation guidance, refer to the provided documentation links and ensure continuous monitoring and updating of security practices to stay ahead of emerging threats.