Comment by unscaled
8 months ago
> OpenID Connect (OIDC) is mostly concerned with authentication. On the other hand, OAuth (or, to be more specific, OAuth v2.0) is concerned with authorization.
That's a common refrain and it's quite inaccurate in that it's using a rather unorthodox definition of these terms. It's like the classic "The United States is not a Democracy, it is a Republic", where the speaker reinterprets Democracy as "Direct Democracy" and Republic as "Representative Democracy"[1].
Same goes for "authorization" and "authentication" in OAuth and OIDC. In the normal sense, authentication deals with establishing the user's identity, while authorization determines what resources the user can access.
Open ID Connect does indeed deal with authentication: it's a federated authentication protocol. The old OpenID also tried to introduce the concept of a globally unique identity in addition to authenticating that identity, as the GP mentioned. But OpenID Connect still supports federation: An application (the consumer) can accepts users logging in through a completely unrelated service (the identity provider). I believe this was originally specified mostly with the idea of third-party authentication in mind (using Google or Apple to log in to another company's service or conversely using your corporate SSO to log in to a SaaS web app), but microservices are very popular nowadays, even services that don't support external login often use OIDC as the authentication protocol between their authentication microservice and other services.
OAuth on the hand, started as a method for constrained access delegation. It allowed web services to issue a constrained access token that is authorized for doing a certain set of operations (defined by the "scope" parameter and often explicitly approved by the user). Getting constrained access through OAuth requires performing authentication, so you can say OAuth is also an authentication standard in a sense. But since OAuth was designed for pure deelgation, it does not provide any user identity information along with its access token, and there was no standard way to use it for federated authentication. Open ID Connect essentially takes OAuth and adds identity information on top. To make things more complicated, there have been a lot of OAuth specifications published as RFCs[2] over the last decade, and a lot of them deal with client authentication and explicitly mentioning Open ID Connect (since arguably most OAuth implementations are also OIDC implementations now).
In short, Open ID Connect is quite accurately described as an Authentication standard. But OAuth 2.0 has little to do with Authorization. It allows clients to specify the "scope" parameter, but does not determine how scopes are parsed, when user and client are permitted to request or grant a certain scope and what kind of access control model (RBAC, ABAC, PBAC, etc.) is used. That's ok, since it leaves the implementers with a lot of flexibility, but it clearly means OAuth 2.0 is not an authorization standard. It only concerns itself with requesting authorization in unstructured form[3].
Better examples for proper authorization standards are declarative authorization specification DSLs like XACML, Alfa, Rego (the language using in Open Policy Agent). I guess you could also put Radius in as an example of a protocol that implements both Authentication and Authorization (although the authorization is mostly related to network resources).
---
[1] To be fair, the meanings of "Democracy" and "Republic" have changed over time, and back in the 18th century, when the US was founded, it was popular to view the Athenian Democracy as the model case of a pure direct democracy and to use the term "Democracy" in this sense. Over time, the meanings changed and we got a weird aphorism that remains quite baffling to us non-Americans.
[3] RFC 9396 is a very recently published optional extension to OAuth that does structured authorization requests, and defines a standard method for resource server to query the requested and granted authorization data.
Agree. I'd say openid connect looks closer to SAML in terms of authenticating users and bootstrapping a "sessions" if you will. OAuth2 in my mind is one potential approach to maintaining a session, post initial authentication, used for ongoing authentication on a per-request basis. It also has information about which client the session is associated with to allow for per-client authorization decisions to be done via the authorization mechanisms you mentioned above.
Basically both are concerned with different parts of Authentication, initial vs on-going (though 2 legged Oauth2 is also an initial authentication step).
The line between authentication and authorization can get quite fine, especially if the authorization policy is as simple as "this set of services can talk to me" if you use mTLS and a fixed set of trusted services in a trust-store.
> In short, Open ID Connect is quite accurately described as an Authentication standard. But OAuth 2.0 has little to do with Authorization. It allows clients to specify the "scope" parameter, but does not determine how scopes are parsed, when user and client are permitted to request or grant a certain scope and what kind of access control model (RBAC, ABAC, PBAC, etc.) is used. That's ok, since it leaves the implementers with a lot of flexibility, but it clearly means OAuth 2.0 is not an authorization standard. It only concerns itself with requesting authorization in unstructured form[3].
This misses the mark - scopes are abstractions for capabilities granted to the authorized bearer (client) of the issued access token. These capabilities are granted by the resource owner, let's say, a human principal, in the case of the authorization_code grant flow, in the form of a prompt for consent. The defined capabilities/scopes are specifically ambiguous as to how they would/should align with finer-grained runtime authorization checks (RBAC, etc), since it's entirely out of the purview of the standard and would infringe on underlying product decisions that may have been established decades prior. Moreover, scopes are overloaded in the OAuth2.0/OIDC ecosystem: some trigger certain authorization server behaviours (refresh token, OIDC, etc), whereas others are concerned with the protected resource.
It's worth noting that the ambiguity around scopes and fine-grained runtime access permissions is an industry unto itself :)
RFC 9396 is interesting, but naive, and for a couple of reasons: 1) it assumes that information would like to be placed on the front-channel; 2) does not scale in JWT-based token systems without introducing heavier back-channel state.
I personally do not view OIDC as an authentication standard - at least not a very good one - since all it can prove is that the principal was valid within a few milliseconds of the iat on that id_token. The recipient cannot and should not take receipt of this token as true proof of authentication, especially when we consider that the authorization server delegates authentication to a separate system. The true gap that OIDC fills is the omission of principal identification from the original OAuth2.0 specification. Prior to OIDC, many authorization servers would issue principal information as part of their response to a token introspection endpoint.
> Same goes for "authorization" and "authentication" in OAuth and OIDC. In the normal sense, authentication deals with establishing the user's identity, while authorization determines what resources the user can access.
"Authorization", in the context of OAuth 2.0, means whether a third-party application is "authorized" to take actions on-behalf-of a resource-owner on some resource server. And, if the answer is yes, what is the "scope" of this "authorization".
From the OAuth 2.0 RFC's abstract[1]:
It's very clear that OAuth2 is all about third-party application and their access to a "resource owner" resource. As far as users and their access to their own resources are concerned, they're "resource owner" and they've all the "power" to do whatever they like (with their own resources–off course).
For example, in the early days of Facebook, FarmVille games needed user permission in order to post on users Facebook walls and/or message users' friends if something interesting happened in the FarmVille while users are/were playing. And this is just one funny example to get across my point; there're many use-cases where it's super useful if users can grant a third-party application permission so that they can do some useful work (whatever it happens to be) on their behalf.
> Better examples for proper authorization standards are declarative authorization specification DSLs like XACML ...
I'm very well familiar with XACML and similar standards about access control policies; actually, I've build/developed an ABAC-based access-control service using XACML-like spec. for one of our customer-facing business application (in the recent past).
Yes, XACML and similar specs. are good for some use-cases for user access / "authorization" (based on business needs and threat-model). Yet, I'm not sure anyone would recommend them for third-party application authorization. Off-course, it's not impossible and it can be done; however, I doubt anyone would recommend doing it when simpler solutions are available–unless there is a strong business case from the business risks and security (threat-modelling) point-of-view.
---
[1] - The OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749
Thank you