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
An Introduction to the Difference Between OAuth Authentication (?) and OpenID for Non-Technical Readers [2023 Edition]
People have long said things like, “OpenID is authentication, while OAuth is authorization.” However, I get the feeling that quite a few people misunderstand what those…
I Asked Genspark to “Summarize OpenID Connect.”
Genspark.ai has a few points that slightly concern me, but it gives a considerably more in-depth answer than Perplexity. Below, I reproduce the answer exactly as…
Public Review of the Final OpenID Connect Core Specifications Has Begun
The 60-day public review of the final OpenID Connect Core specifications has begun. The drafts under public review are as follows. OpenID Connect Core - Defines a…