It is often said that OpenID is for authentication and OAuth is for authorization. This was originally something that people involved with OAuth in the United States started saying.
Of course, it is wrong.
This becomes clear when comparing the sequences of OpenID and OAuth, particularly OpenID’s Artifact Binding and OAuth’s. As is immediately apparent, they are almost identical. The differences are as follows:
- In OAuth, a Consumer Key and Consumer Secret are obtained. In OpenID, the equivalent of the Consumer Key is the realm, while the equivalent of the Consumer Secret is obtained dynamically as an Association.
- The Identity used in OAuth is the Identity that the user registered with the relevant Service Provider. In OpenID, the Service Provider is dynamically identified from the Identity selected by the user.
- In OpenID, parameters are basically all sent as HTTP queries. OAuth also uses HTTP Headers.
These would be the principal differences.
In other words, OAuth is a framework operating within static relationships centered on the Service Provider, whereas OpenID is a framework operating within dynamic relationships centered on the User. OAuth is simpler because it eliminates the need for dynamic “Discovery,” but what it “gives up” in doing so is the philosophy and functionality of user-centricity.
In a word, it could be described as follows.
- OAuth is service-provider-centric but simpler
- OpenID is user-centric but more complex
That said, OpenID also has a bug in the discovery specification that prevents proper delegation except when using XRI, so it ultimately results in lock-in by the Service, but this is a matter of philosophy… Presumably this will be properly fixed in 3.0.
That is why I am more enthusiastic about OpenID than OAuth.
As for how OAuth might be used, I see it more as an underlying protocol for OpenID. However, it has a few too many things packed into it for that purpose, and Wrap seems easier to use in that respect.
(Table 1) Comparison of OpenID and OAuth
| Item | OpenID | OAuth |
|---|---|---|
| Name of IdP | OP (OpenID Provider) | SP (Service Provider) |
| Name of RP | RP | Consumer |
| Identification of RP | Automatically identified from the realm | Consumer Key obtained manually in advance |
| Exchange of signing keys | Dynamically exchanged through Association | Manually exchanged in advance |
| User identifier | OpenID-enabled identifier selected by the user | Identifier assigned to the user by the SP |
| Name of Artifact | Artifact | Request Token |
| Name of Assertion | Assertion | Access Token |
| Underlying philosophy | User-centricity | Service-provider (application) centricity |
Related posts
When Software Becomes Staff: Governance, Security, and Safety for Agentic AI
Below is the transcript of my keynote speech at EIC 2026 on May 19, 2026. The slides are provided as a PDF at the end of…
OpenID Summit Tokyo 2026 “Special Edition” Closing Keynote
The tickets apparently sold out instantly, so I had not introduced this event here; however, tomorrow, August 26, I will appear at the OpenID Summit Tokyo…
On May 19, I Will Deliver a Keynote at EIC 2026 in Berlin, Titled “When Software Becomes Staff: Governance, Security & Safety for Agentic AI”
On the first day of EIC 2026, I will deliver the keynote “When Software Becomes Staff: Governance, Security & Safety for Agentic AI.”