OAuth 2.0 Authorization (Authz Response Leaks)

This is an analysis of various OAuth flows under the assumption that the authorization response leaks and no other attacks are performed on the OAuth flows (e.g., endpoints are configured correctly and do not act maliciously, etc.).

Security Properties

• Authorization: The attacker cannot get hold of or use an access token that was issued for another user. (green=true, red=false, grey=unknown)

Rules used

(see labels in graph below)

• Code Leaks + Injection: If an authorization code leaks from the authz response, and is not protected by PKCE or the id token nonce, then the flow must be insecure. The attacker can circumvent client authentication as follows: He starts a new OAuth flow with the same client that the user used and injects the stolen code into the authorization response before it is sent to the client. The client will then use its client credentials to authenticate at the token endpoint.
• Code Leaks: If an authorization code leaks from the authz response, and is not protected by PKCE or the id token nonce, then the flow must be insecure. Without client authentication, the attacker can use the stolen code at the token endpoint and exchange it for an access token that gives access to the user's resources. (The attacker can spoof the client id.)
• No Code Injection: If PKCE or nonce are used, a code in the authorization response can leak, but the response will still be secure.
• Leaked AT: If a token leaks from the authorization response, an attacker can immediately use this token at the resource server, which break authorization.