6 ms·

This might answer some questions: https://openid.net/connect/faq/ https://openid.net/connect/faq/ Also >Are there live production deployments of OpenID Connec

This might answer some questions: https://openid.net/connect/faq/ https://openid.net/connect/faq/ Also >Are there live production deployments of OpenID Connect? Yes. Some examples include Google, Gakunin (Japanese Universities Network), Microsoft, Ping Identity, Nikkei Newspaper, Tokyu Corporation, mixi, Yahoo! Japan and Softbank. There are also mature deployments underway by Working Group participant organizations, such as Deutsche Telecom, AOL, and Salesforce. For an example of OpenID Connect at work, look at Google+ Sign-In, Google’s flagship social-identity offering, which is entirely based on OpenID Connect.

jrockway 7y ago
Is OpenID Connect the one where it issues a JWT that you can then verify and exchange for a session cookie? If so, I love the API. Very easy to use, and easy to integrate multiple sources.
- pas 7y ago
  Yes. It's OAuth2 with some additional formalism/standardization.
- user5994461 7y ago
  Short answer is yes but long answer is no. OpenID Connect doesn't define anything about the token format or the use of cookies. It's really more of an authentication framework, that leaves a lot to the implementation. Web is always cookies and JWT is getting popular lately.
  - unscaled 7y ago
    Only partially correct. I think the earliest drafts of OpenID Connect were completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect Core spec is tightly coupled to the JWT standard in multiple places. The first and most important coupling point is the ID Token. There are three types of tokens issued by Open ID Connect: Access Tokens and Refresh tokens are opaque, just as in OAuth 2. ID Tokens, on the other hand, most follow a more-or-less well-defined JWT format (as much as JWT can be well-defined - it is a somewhat wild west of a standard). The rest of the places you could use JWT are in the spec, but I admit I've never seen them in the wild (and I would probably avoid them like the plague if I was trying to implement a _secure_ subset of an OpenID Connect IdP): 1. JWT request signing (and even encryption!) 2. JWT for signing and encrypting any JSON response 3. JWT for client authentication 4. JWT for aggregated claims And I may have missed more things. If you want to implement Open ID Connect without being crazy, forget about all of these and only use/implement the Auth Code flow with a client secret. You should still verify the ID Token according to the spec, but if you fail to verify it's no longer an issue, since this is a value you get directly from the the Authorization Server on an authenticated TLS channel (the same channel you'd trust for getting the ID Token signing keys).
    - user5994461 7y ago
      OpenID Connect predates JWT so it certainly couldn't have been used from the beginning. I'm not aware if there is a re edition of the spec. Either way, pretty much everything in OpenID Connect is optional and/or implementation specific. OIDC providers have to be integrated one by one, adjusting to their slight differences.
      - TJSomething 7y ago
        OpenID Connect Core, section 2: "The ID Token is represented as a JSON Web Token (JWT) [JWT]." (https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...)
        user5994461 7y ago
        Well, that's good to know on the one hand. On the other hand, I've never seen a provider that respected that section in full.
        andyroid 7y ago
        Huh? The ID token and it’s claims is one of the core concepts of OIDC. Are you thinking of OAuth? That spec says nothing about token formats.
        unscaled 7y ago
        This is more or less one of the only part that is respected in full. I've got to say, I've seen providers without proper discovery, I've seen providers with strange hybrid flows and I'm pretty sure most providers don't implement the request/response signing and encryption (after all, if you want insanity, you'll be more than happy with SAML). But I've never seen a provider who doesn't implement an ID token. I think everybody would agree that OpenID Connect without an ID token is just plain OAuth 2.
        user5994461 7y ago
needle0 7y ago
Strange that the examples given are heavily skewed towards websites in Japan (Gakunin, Nikkei, Tokyu, Mixi, Yahoo Japan, Softbank). Also, I guess they ought to be updating that text now that Google+ is dead.
- jeremyjh 7y ago
  The brand Google+ is dead, the sign on service that was part of its API lives on in the Google Identity Platform. If you ever click "Sign-On With Google" you are using it. If you use a different authentication provider - like Github or Facebook or Linked In, you are still using Open ID Connect. Its actually bizarre that Apple did this the way they did.
  - encoderer 7y ago
    In fact, it’s everywhere now. Pinterest, Zillow, NewEgg just to name a few.
- unscaled 7y ago
  The writer is Japanese, so he might be basing this on personal experience. This is not a good list to sway Apple with, even if they had experience with Japan. The first 3 are not tech companies. Tokyu in particular is a huge conglomerate and they have many different companies with separate user bases. I've never seen any of them using OpenID Connect.

jrockway 7y ago

Is OpenID Connect the one where it issues a JWT that you can then verify and exchange for a session cookie? If so, I love the API. Very easy to use, and easy to integrate multiple sources.

pas 7y ago
Yes. It's OAuth2 with some additional formalism/standardization.
user5994461 7y ago
Short answer is yes but long answer is no. OpenID Connect doesn't define anything about the token format or the use of cookies. It's really more of an authentication framework, that leaves a lot to the implementation. Web is always cookies and JWT is getting popular lately.
- unscaled 7y ago
  Only partially correct. I think the earliest drafts of OpenID Connect were completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect Core spec is tightly coupled to the JWT standard in multiple places. The first and most important coupling point is the ID Token. There are three types of tokens issued by Open ID Connect: Access Tokens and Refresh tokens are opaque, just as in OAuth 2. ID Tokens, on the other hand, most follow a more-or-less well-defined JWT format (as much as JWT can be well-defined - it is a somewhat wild west of a standard). The rest of the places you could use JWT are in the spec, but I admit I've never seen them in the wild (and I would probably avoid them like the plague if I was trying to implement a _secure_ subset of an OpenID Connect IdP): 1. JWT request signing (and even encryption!) 2. JWT for signing and encrypting any JSON response 3. JWT for client authentication 4. JWT for aggregated claims And I may have missed more things. If you want to implement Open ID Connect without being crazy, forget about all of these and only use/implement the Auth Code flow with a client secret. You should still verify the ID Token according to the spec, but if you fail to verify it's no longer an issue, since this is a value you get directly from the the Authorization Server on an authenticated TLS channel (the same channel you'd trust for getting the ID Token signing keys).
  - user5994461 7y ago
    OpenID Connect predates JWT so it certainly couldn't have been used from the beginning. I'm not aware if there is a re edition of the spec. Either way, pretty much everything in OpenID Connect is optional and/or implementation specific. OIDC providers have to be integrated one by one, adjusting to their slight differences.
    - TJSomething 7y ago
      OpenID Connect Core, section 2: "The ID Token is represented as a JSON Web Token (JWT) [JWT]." (https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...)
      - user5994461 7y ago
        Well, that's good to know on the one hand. On the other hand, I've never seen a provider that respected that section in full.
        andyroid 7y ago
        Huh? The ID token and it’s claims is one of the core concepts of OIDC. Are you thinking of OAuth? That spec says nothing about token formats.
        unscaled 7y ago
        This is more or less one of the only part that is respected in full. I've got to say, I've seen providers without proper discovery, I've seen providers with strange hybrid flows and I'm pretty sure most providers don't implement the request/response signing and encryption (after all, if you want insanity, you'll be more than happy with SAML). But I've never seen a provider who doesn't implement an ID token. I think everybody would agree that OpenID Connect without an ID token is just plain OAuth 2.
        user5994461 7y ago

needle0 7y ago

Strange that the examples given are heavily skewed towards websites in Japan (Gakunin, Nikkei, Tokyu, Mixi, Yahoo Japan, Softbank). Also, I guess they ought to be updating that text now that Google+ is dead.

jeremyjh 7y ago
The brand Google+ is dead, the sign on service that was part of its API lives on in the Google Identity Platform. If you ever click "Sign-On With Google" you are using it. If you use a different authentication provider - like Github or Facebook or Linked In, you are still using Open ID Connect. Its actually bizarre that Apple did this the way they did.
- encoderer 7y ago
  In fact, it’s everywhere now. Pinterest, Zillow, NewEgg just to name a few.
unscaled 7y ago
The writer is Japanese, so he might be basing this on personal experience. This is not a good list to sway Apple with, even if they had experience with Japan. The first 3 are not tech companies. Tokyu in particular is a huge conglomerate and they have many different companies with separate user bases. I've never seen any of them using OpenID Connect.