This field-guide entry has not been reviewed in its new form yet. The studies are summarized as published; no review date is implied.
Key findings #
Testing 6 OpenID Certified identity providers and 8 service providers against 11 service provider attacks and 7 identity provider attacks uncovered 12 implementation flaws.
Mladenov and Mainka classify session overwriting and IdP confusion as flaws in the OpenID Connect specification itself, separate from implementation bugs.
The attacks in the OpenID Connect Security Considerations report work for a web attacker who sends ordinary HTTP requests and has no control over the network.
Evidence #
| Study | Year | Sample | Method | Finding |
|---|---|---|---|---|
| Security Analysis of Real-Life OpenID Connect ImplementationsRuhr-University Bochum | 2020 | 6 identity providers, 8 service providers | Docker lab with PrOfESSOS, automatic and manual tests | 18 attack types tested; 12 implementation flaws disclosed. |
| OpenID Connect Security ConsiderationsRuhr-University Bochum | 2017 | n/a | Technical report on specification and implementation flaws | Catalogues attacks on clients and providers with defence recommendations. |
What to do #
For engineers #
On the relying party:
- Validate every ID token: signature with a key from the expected issuer’s key set, algorithm, issuer, audience, expiry and nonce. Signature manipulation, key confusion, token recipient confusion and replay attacks all exploit a missing check. My essays on JWKS and the purpose of JWT cover the token side.
- Bind each login to the browser session that started it, and remember which identity provider you sent the user to. Session overwriting and IdP confusion exploit clients that don’t.
- Identify users by issuer and subject together, never by subject or email alone.
On the OpenID provider:
- Compare redirect URIs exactly against the registered values.
- Enforce PKCE for clients that started with it, so an attacker can’t downgrade the flow.
- Accept each authorization code once and only from the client it was issued to.
For product and UX #
- Treat “OpenID Certified” as a conformance signal, not a security audit. Fries tested certified implementations and still disclosed 12 flaws. When you choose a library or vendor, ask for penetration test results that cover these attack classes.
- If your product offers several identity providers, show users which one they’re signing in with. IdP confusion attacks rely on the client mixing them up.
The studies in detail #
Security Analysis of Real-Life OpenID Connect Implementations #
In this Master’s thesis from December 2020, Christian Fries presents a Docker-based lab environment for developers and penetration testers. The lab helps to find security flaws in real-world OpenID Connect Certified service provider and identity provider implementations, and it includes the PrOfESSOS tool for automatic tests. Fries selected 6 identity providers and 8 service providers that support the implicit and hybrid flows. He tested them against 11 service provider attacks and 7 identity provider attacks and disclosed 12 implementation flaws to the developers.
The thesis also describes common threats and attack scenarios. These include single- and cross-phase attacks on relying parties, like token substitution, key confusion and replay attacks. It also covers attacks on OpenID providers, like message flow confusion, PKCE downgrade and sub claim spoofing.
OpenID Connect Security Considerations #
In this 2017 technical report, Vladislav Mladenov and Christian Mainka from Ruhr-University Bochum look at OpenID Connect specification flaws and implementation issues that open up attack vectors. They outline attack scenarios like session overwriting, redirect URI manipulation and token recipient confusion, and give recommendations for defending against them.