5 ms·

You may already know this, I'm writing it as a note for my future self. OpenID Connect (OIDC) is mostly concerned with authentication. On the other hand, OAuth

by alasr 2y ago

You may already know this, I'm writing it as a note for my future self. 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. >> OpenID Connect is effectively an evolution of OAuth. In my opinion, OpenID Connect is actually evolution of OpenID – in its vision/spirit: - OIDC, like OpenID, primarily focuses on users' identity and authentication; - OIDC, unlike OpenID, didn't (re)invent new authentication workflows, which were significantly different in their own ways. Instead, it built authentication workflows on top of existing OAuth spec (which was being (ab)used for authentication in some places which, unfortunately, is still the case) to achieve its main objective (i.e. authentication). --- Edit: rephrased to better communicate my thoughts (still not perfect; but, as the saying goes, perfect is the enemy of the good so I stop here).

wtallis 2y ago
> OIDC, unlike OpenID, didn't (re)invent new authentication workflows, which were significantly different in their own ways. Instead, it built authentication workflows on top of existing OAuth spec Didn't OpenID predate OAuth? What should OpenID have built upon?
- alasr 2y ago
  >> Didn't OpenID predate OAuth? What should OpenID have built upon? Yes, you're right about "OpenID predate OAuth" part. However, from my point-of-view, it seems the main source of confusion here is due to the fact that the word OpenID is used in more than one sense: - First, OpenID used as part of the original OpenID authentication protocol developed around 2005 which communicates the idea of a decentralized online digital identity where one way a user can asserts their online digital identity is via a URL under their control. - Second, OpenID used as part of the compound noun in "OpenID Connect" (which as per Wikipedia is "third generation of OpenID technology", published in 2014[1]) which implements the user identity and their authentication via authentication workflows built on top of OAuth2 spec. Now, in my comment earlier i.e. "OIDC, unlike OpenID, ... built on top of existing OAuth spec ... to achieve its main objective ...", I was using OIDC (with "OpenID") in the second sense in comparison to the original OpenID authentication protocol where OpenID is used in the first sense (with both senses mentioned above). I hope it helps. --- As an aside, looking at all the comments about "OpenId" and "OpenID Connect" as nouns, I'm reminded of the following post: Two Hard Things[2] --- [1] - https://en.wikipedia.org/wiki/Openid#OpenID_Connect_(OIDC) https://en.wikipedia.org/wiki/Openid#OpenID_Connect_(OIDC) [2] - https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html
- thayne 2y ago
  Yes. But OpenID Connect came much later, and is based on OAuth 2.0.
simonw 2y ago
My problem with it being called OpenID Connect is that, in my head, an OpenID is a noun which means "a URL that you can use as your identity and prove that you own". That definition doesn't work for OpenID Connect. Is OpenID a noun any more? I don't think it is.
- clhodapp 2y ago
  OpenID Connect can totally work that way if used with WebFinger for endpoint discovery, and occasionally this is implemented (though many websites do not).
  - pas 2y ago
    Hm, so the point of adding this additional hop (which is also a JSON under the .well-known/ prefix), is that I can always put the domain of my homepage into WebFinger aware OIDC login boxes, no need to remember the domain of my OIDC provider?
    - shadowfacts 2y ago
      Yes. This is how, for example, Tailscale implements bring-your-own identity provider: https://tailscale.com/blog/custom-oidc https://tailscale.com/blog/custom-oidc It is, to date, the only non-selfhosted service with which I can use my self-hosted SSO setup.
      - francislavoie 2y ago
        I feel like I remember StackOverflow (and related sites) having OpenID login as an option, but I don't see it anymore. I figure they removed it due to low popularity.
        yrro 2y ago
        Sourceforge used to have it too!
        2y ago
unscaled 2y 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. [2] https://oauth.net/2/ https://oauth.net/2/ [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.

by alasr 2y ago

wtallis 2y ago

> OIDC, unlike OpenID, didn't (re)invent new authentication workflows, which were significantly different in their own ways. Instead, it built authentication workflows on top of existing OAuth spec Didn't OpenID predate OAuth? What should OpenID have built upon?

alasr 2y ago
>> Didn't OpenID predate OAuth? What should OpenID have built upon? Yes, you're right about "OpenID predate OAuth" part. However, from my point-of-view, it seems the main source of confusion here is due to the fact that the word OpenID is used in more than one sense: - First, OpenID used as part of the original OpenID authentication protocol developed around 2005 which communicates the idea of a decentralized online digital identity where one way a user can asserts their online digital identity is via a URL under their control. - Second, OpenID used as part of the compound noun in "OpenID Connect" (which as per Wikipedia is "third generation of OpenID technology", published in 2014[1]) which implements the user identity and their authentication via authentication workflows built on top of OAuth2 spec. Now, in my comment earlier i.e. "OIDC, unlike OpenID, ... built on top of existing OAuth spec ... to achieve its main objective ...", I was using OIDC (with "OpenID") in the second sense in comparison to the original OpenID authentication protocol where OpenID is used in the first sense (with both senses mentioned above). I hope it helps. --- As an aside, looking at all the comments about "OpenId" and "OpenID Connect" as nouns, I'm reminded of the following post: Two Hard Things[2] --- [1] - https://en.wikipedia.org/wiki/Openid#OpenID_Connect_(OIDC) https://en.wikipedia.org/wiki/Openid#OpenID_Connect_(OIDC) [2] - https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html
thayne 2y ago
Yes. But OpenID Connect came much later, and is based on OAuth 2.0.

simonw 2y ago

My problem with it being called OpenID Connect is that, in my head, an OpenID is a noun which means "a URL that you can use as your identity and prove that you own". That definition doesn't work for OpenID Connect. Is OpenID a noun any more? I don't think it is.

clhodapp 2y ago
OpenID Connect can totally work that way if used with WebFinger for endpoint discovery, and occasionally this is implemented (though many websites do not).
- pas 2y ago
  Hm, so the point of adding this additional hop (which is also a JSON under the .well-known/ prefix), is that I can always put the domain of my homepage into WebFinger aware OIDC login boxes, no need to remember the domain of my OIDC provider?
  - shadowfacts 2y ago
    Yes. This is how, for example, Tailscale implements bring-your-own identity provider: https://tailscale.com/blog/custom-oidc https://tailscale.com/blog/custom-oidc It is, to date, the only non-selfhosted service with which I can use my self-hosted SSO setup.
    - francislavoie 2y ago
      I feel like I remember StackOverflow (and related sites) having OpenID login as an option, but I don't see it anymore. I figure they removed it due to low popularity.
      - yrro 2y ago
        Sourceforge used to have it too!
      - 2y ago

unscaled 2y 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. [2] https://oauth.net/2/ https://oauth.net/2/ [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.