OAuth2 and OIDC vulnerable?

December 29, 2025

Tags: #oauth #oidc #security #vulnerability #pkce

A few weeks ago I attended a conference talk, where the speaker teased to me in advance, that she will talk about a possible OAuth vulnerability, a combination of open redirects and no proper redirect uri check. That caught my attention…

After all, the scenario demonstrated was a real-life scenario and showed what happens when you use deprecated security features or ignore all good advice and fail to adapt your environment to changes over time and new best practices.

It turned out that the application shown used the Implicit Grant, which is now marked as deprecated and should not be used in RFC 9700 (Best current security practices in OAuth2). This grant type redirects the user back to the application after successful login with the access token (and ID token, if applicable) in the query parameters. If the user is not redirected to the application, but to a redirect URI that has not been sufficiently verified by the IdP and has been manipulated by a man-in-the-middle attacker, as in the example shown, the attacker can obtain the token and abuse it. This is a scenario that MUST be avoided under all circumstances! An access token owner can use it without restriction as long as no additional measures such as DPoP (Demonstrating Proof of Possession, RFC 9449) are applied!

The use of the Implicit Grant is deprecated for good reasons and should not be used. The application in the example shown did not require the use of the Implicit Grant. Instead, the Authorization Code Grant would have been the more appropriate way to go. It was simply due to a lack of knowledge or incorrect knowledge on the part of the developer.
Human failure!

If the application is converted to use the Authorization Code Grant in conjunction with a confidential client that can identify itself to the IdP using client credentials, and PKCE (Proof Key for Code Exchange, RFC 7636) is used in addition, it will be nearly impossible for an attacker to exchange the authorization code instead of the actually authorized client (the application) and thus illegaly obtain a token.

OAuth2 and OIDC are therefore not vulnerable; rather, it is still the human factor that, with a lack of knowledge or incorrect knowledge, ignores best practices and seemingly “knows better”. Don’t make the same mistake! Don’t shift the responsibility from yourself to the specification(s). If you are missing information, please get in touch with me. I can help you make your application landscape secure with regard to OAuth, OIDC, and authentication!

« KEYCLOAK Friday live chat Xmas edition - Auth.it w/ GR Patil from Phase Two KeycloakCon Europe 2026 in Amsterdam »