What's the key takeaway of the report? It identifies a few vulnerabilities in the OAuth 2.0 protocol, but they're largely theoretical and edge cases. As all security implementations go, it demonstrates that, when OAuth is implemented according to the recommendations (refer to RFC 6749 and RFC 6819), it's indeed a secure protocol.
In this paper, the researchers identified two attack vectors: the authorization code and implicit grant types, both related to redirect-based flows. Here's the general two-step data flow for these grant types:
Step 1: A client redirects a user (via the browser) to the OAuth 2.0 authorization server (AS) to approve authorization. Generally, in this step, the AS performs user authentication as well. If authorized, the AS will then redirect the user back to the client with either the access token in a URL fragment (implicit flow) or with a code that the client exchanges for the tokens (authorization grant flow).
Step 2: The client can then use the tokens provided to access protected resources.
The security analysis also identified two attack vectors:
1. Explicit OAuth permission of any HTTP redirect (aka, 307 redirect): This attack depends on how the AS redirects the user to the client after the authorization step (i.e., the redirect in step 2). A typical redirect uses the 302 HTTP redirect status code to tell the browser to load a different site. However, if the AS uses a different status code (i.e., the 307 status code), this can cause the contents of the original POST to be replayed to the new host. In this case, the username/password presented to the AS could be provided to the malicious client.
This is a theoretical attack. The OAuth specification doesn't explicitly describe how the AS should redirect the user. The PingFederate OAuth AS uses a 302 status code to redirect, so it's not susceptible to this attack.
2. Confused relying party (aka, IdP mix-up): This attack may occur when a client interacts with multiple OAuth authorization servers. In this scenario, a malicious AS may confuse the client into thinking that the malicious AS is, in fact, the real AS. This can lead to sensitive information like client secrets, codes, and tokens getting leaked to the malicious AS.
If your deployment has one client interacting with multiple identity providers or authorization servers, or you're planning to support this deployment configuration in the near future, please follow the recommendations in security bulletin (SECBL008) (available in the customer portal) to mitigate this attack.
It's important to note that the OAuth community is considering a fix for this that'll be included in updates to the OAuth spec. This will allow customers to handle this vulnerability in a standards-based way once implementations are available.
Ping Identity products such as PingFederate and PingAccess go through security engineering practices to mitigate our risk and yours. As always, developers working with standards like OAuth 2.0 should ensure they're following best practices and reviewing the security advisory to be sure their client implementations are safe from these attacks.