E Best Practices for Oracle Access Manager (OAM) OAuth Security
With the growing adoption of OAuth for API protection and federated login via OpenID Connect, the Internet Engineering Task Force (IETF) has published OAuth 2.0 Security Best Practices. This section highlights possible threats, details attacker capabilities, and offers strategies to mitigate those risks.
Protecting Redirect-based Flows
- Complaint processing:
- Matching client redirect URIs against pre-registered URIs
- CSRF prevention
- Use of
PKCE[2]with a strict PKCE setting to prevent downgrade attacks - Confidential OpenID Connect clients can use the nonce parameter
- Secure Client Registration
- Clients SHOULD NOT use the implicit grant (response type
token) or other response types when issuing access tokens in the authorization response - Clients MUST only use secure Client Types
- Allowing a client to be registered to use one or more grant types
- Clients SHOULD NOT use the implicit grant (response type
- Generation of the iss Claim in issued tokens
- 307 redirects are not supported, which prevent accidental forwarding of a request containing user credentials
As there is no standardized method for sender-constraining, binding an access token to a specific client during the authorization response leaves the system vulnerable. If an access token is exfiltrated (leaked or copied), an attacker could use it at a resource endpoint. For this reason, the use of the Implicit Grant and similar response types is discouraged unless effective measures are implemented to prevent access token injection.
Token Replay Prevention
OAM OAuth has the capability to detect refresh token reuse and automatically revoke all issued refresh tokens. To prevent access token injection and replay attacks, it's essential to bind a token to a specific client. OAM OAuth mitigates this threat by enabling the use of mTLS (Mutual TLS) for sender-constrained access and secure grant types. It is recommended to keep the lifetime of issued tokens as short as necessary to minimize risk.
Access Token Privilege Restriction
Deployments must adhere to the principle of least privilege. All access tokens issued by OAM OAuth must include audience restrictions and claims. In addition, Clients and Resource Servers MUST verify both the scope and audience of the token before granting access to ensure proper authorization.
Resource Owner Password Credentials Grant
The resource owner password credentials grant MUST NOT be used as it exposes the credentials of the resource owner to the client. OAM OAuth allows explicit client configuration with the list of secure grant types to prevent use of insecure grant types. OAM OAuth supports Resource Owner Password Credentials Grant for backward compatibility.
Client Authentication
Sender-constraining client authentication is recommended. OAM supports both
mTLS[3] and private_key_jwt[4] methods for
client authentication, which use asymmetric cryptography.
Other Recommendations
The OAM server publishes metadata that clients can use to securely configure themselves. This ensures that the OAM OAuth server only publishes secure settings, helping to prevent clients from being misconfigured.
Attacks and Mitigations
Table E-1 Attacks and Mitigations
| Attack Class | Attack Type | Countermeasures | OAM OAuth |
|---|---|---|---|
| Insufficient Redirect URI Validation | Redirect URI Validation Attacks on Authorization Code Grant | Use exact URI matching of redirect URI, avoid wildcard URI matching | Implements exact URI matching and redirection to whitelisted URLs |
| Redirect URI Validation Attacks on Implicit Grant | Client SHOULD use authorization code instead of response type causing token issuance at the authorization endpoint | Supports using PKCE | |
| Insecure HTTP scheme used for redirect URI | Client SHOULD invalidate state value after its first use at the redirection endpoint. | Supports http redirect for backwards compatibility but Clients using it need to be monitored | |
| Credential Leakage via Referrer Headers | Leakage from the OAuth Client | Confidential Clients MUST be able to secure store OAuth configuration including security artifacts | Generates diagnostics and audit logs to record OAuth activity |
| Leakage from the Authorization Server | Clients MUST periodically renew their security artifacts | ||
| OAM Administrators MUST monitor access logs and audit data to detect fraudulent access patterns | |||
| The state value SHOULD be invalidated by the client after its first use at the redirection endpoint | |||
| Credential Leakage via Browser History | Authorization Code in Browser History | Clients MUST NOT pass access tokens in a URI query parameter. The authorization code grant or alternative OAuth response modes like the form post response mode can be used. | Supports form post [5] responses |
| Access Token in Browser History | |||
| Mix-Up Attacks | Compromised Authorization server tricking Client to release Credentials issued by an Uncompromised Server | Clients MUST store, for each authorization request, the issuer they sent the authorization request to and bind this information to the user agent. Clients MUST validate the issuer for the token received. | Interacting Clients need to be compliant |
| Clients MUST use a distinct redirect URI for each issuer they interact with. Clients MUST check that the authorization response was received from the correct issuer by comparing the distinct redirect URI for the issuer to the URI where the authorization response was received on. | |||
| Authorization Code Injection | Replay of an authorization code | Clients MUST using PKCE and Nonce. This will allow the validation of the authorization code request to make sure that the code was issued to the requester and no intermediary is injecting a different authorization code in the client response. | Interacting Clients need to be compliant |
| Access Token Injection | Injection of an exfiltrated (stolen / copied) access token | Access Token lifetimes must be kept as small as possible | Countermeasures supported |
| Use OpenID connect which can mitigate this attack | |||
| Use sender-constrained access token to prevent attackers from obtaining access tokens | |||
| Cross-Site Request Forgery | Inject a request from the victim's device to the redirect URI of a legitimate Client | Use PKCE | Countermeasures supported |
| Otherwise, inject an anti-CSRF token into the state or nonce parameter in OAuth interactions | |||
| PKCE Downgrade Attack | Clients MUST use PKCE and enable Strict PKCE flag with state validation to prevent CSRF attacks. | Countermeasures supported | |
| Access Token Leakage at the Resource Server | Access Token Phishing by Counterfeit Resource Server | Use sender-constrained access tokens | Countermeasures supported |
| Compromised Resource Server | Use and Claim | Resource Servers need to be compliant | |
| Resource Server must be hardened and protect sensitive data | |||
| Misuse of Stolen Access Tokens | Sender-Constrained Access Tokens | Use Sender-constrained access tokens | All Issued tokens include the aud Claim |
| Audience-Restricted Access Tokens |
A reverse proxy MUST therefore sanitize any inbound requests to ensure the authenticity and integrity of all header values relevant for the security of the application servers. Resource Server MUST validate the scope and the audience before granting access |
Use mTLS sender verification at resource server | |
| Open Redirection | Client as Open Redirector | Redirect is done only if the target URLs are allowed or if the origin and integrity of a request can be authenticated | Can only redirect to whitelisted URLs |
| Authorization Server as Open Redirector | Implements exact Redirect URI matching | ||
| 307 Redirect | Potential Leakage of credentials during a redirect | Disable 307 Redirect | Not supported |
| TLS Terminating Reverse Proxies | Lack of input sanitization | Use end-to-end TLS | Deployment must be configured to use TLS Everywhere. |
| Refresh Token Protection | Replay of refresh tokens |
Use send-constrained refresh tokens Enable automatic detection of refresh token re-use followed by cancellation of all issued refresh tokens |
Countermeasures supported. |
| Client Impersonating Resource Owner | Client accidentally accesses resources belonging to resource owners | Authorization servers SHOULD NOT allow clients to influence their client_id or any claim that could confuse Resource Servers | Discourage use of grant types that do not distinguish between Clients and Resource owner |
| Use access tokens that include the sub Claim | |||
| Clickjacking | No Origin of frame restrictions | Use OWASP anti-clickjacking mechanisms | Countermeasures supported |
| Attacks on In-Browser Communication Flows | Insufficient Limitation of Receiver Origins | Use HTTP POST over HTTP Redirect | Requires a defense in depth approach |
| Insufficient URI Validation | Avoid use of wildcard URIs | Monitoring the deployment for malicious access is necessary. | |
| Injection after Insufficient Validation of Sender Origin | Apply mechanisms to protect the authorization response |