4 ms·

> If you are writing a new application, use OpenID Connect–skate to where the puck is going! I am glad to see this advice. At CoreOS we have now built API serv

by philips 10y ago

> If you are writing a new application, use OpenID Connect–skate to where the puck is going! I am glad to see this advice. At CoreOS we have now built API servers, command line tools, and web apps using OpenID Connect and are happy with its development in Open Source and third-party services as well. > OAuth2 was left generic so that it could be applied to many authorization requirements, When we started developing Dex[1] we lovingly referred to OpenID as "OAUTH 2.0 with types". Overall, from integrating OpenID Connect into our products, enabling Kubernetes[2] to use OpenID Connect Providers, and building both an OpenID Connect provider and clients we are pretty happy with the choice we made. My only complaint is the name of OpenID Connect is simply confusing. [1] https://github.com/coreos/dex https://github.com/coreos/dex [2] http://kubernetes.io/docs/admin/authentication/#openid-connect-tokens http://kubernetes.io/docs/admin/authentication/#openid-conne...

willow9886 10y ago
> My only complaint is the name of OpenID Connect is simply confusing. Yea..many people only remember the failed OpenID 1 & 2 specs...so, out-of-the-box there is some developer fatigue associated with Connect. However, federation standards have proven to be pretty sticky--SAML was written 10+ years ago. Hopefully as Connect continues to be developed, marketed, and implemented by developers, it will over shadow previous unsuccessful versions of the protocol.
- philips 10y ago
  I have just started saying OIDC as that has no fatigue attached to it. And then if people want clarification I explain the whole silly naming story.
- user5994461 10y ago
  Don't confuse OpenID and OpenID Connect. They are very different things.
  - pyvpx 10y ago
    with very similar names?
    - user5994461 10y ago
      They shouldn't have had similar names. This is causing a lot of confusion ^^
      - nailer 10y ago
        OpenID has a bad enough reputation amongst developers - with the user being asked to remember bizarre URLs - that I'm surprised they kept the name.
- idm_guru 10y ago
  It's no more confusing then LDAP. First there was LDAP 1.0, 2.0, now we all use 3.0... OpenID 2.0 is deprecated. Don't use it. The current OpenID authentication protocol = OpenID Connect. In the not too distant future, no one will even remember that something called OpenID 2.0 existed. Maybe OpenID Connect should be OpenID 3.0? I think the idea was to show alignment with Facebook Connect's design...but more open. Remember, at the time Facebook Connect provided some good data--it was a massive user acceptance test. IMHO, the blame lies with the OIDF for not delivering this message. OpenID Connect has been final for 4+ years. What's taking so long? Maybe it's not in the interest of the OIDF's controlling board members to promote this distributed identity infrastructure? MSFT wants you to use Azure AD. Google wants you to use their IDP. Maybe they don't want to promote until they have product ready? Stay tuned... I think when it's in the interest of the current finanical backers of the OIDF to promote OpenID Connect, no one will remember that old OpenID 2.0 thing.
- WorldMaker 10y ago
  There's also a flipside too: those of us that remember the original community grassroots spirit and attempted simplicity of early OpenID and feel like OpenID Connect misses a lot of the old point of OpenID, and definitely a lot of the intended simplicity.
philips 10y ago
And as if to prove my point LWN just ran an article on OpenID https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/ https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/
- willow9886 10y ago
  This is maddening! OpenID Connect is not an extension of OpenID 1 & 2--it is basically a complete re-write!
spangry 10y ago
When I did a short 6 month stint at the Australian version of the GDS (the 'Digital Transformation Office', or DTO), my team stood up a prototype/demo of an attributes-based 'digital identity' system using OIDC. It's almost ideal for the government use-case: private sector IDCs can offer identity/attribute verification services if the government provides an assurance and audit framework. The potential number of digital commercial transactions this could enable are mind-boggling. It's also privacy-preserving due to its attributes-based approach to access control and its federated nature. Also likely to result in a competitive market for IDCs instead of YAGM (yet another government monopoly) due to the low (technical) barrier to entry: I'm a terrible programmer and I spent less time coding a mock RP/client implementation straight from the spec than I did searching around for pre-canned libraries (which didn't seem to exist at the time). It's a shame no-one would listen to us. From what I hear, they're going with some kind of centralised RBAC system. Boy it's going to be fun when some welfare payment or tax concession eligibility criteria is tweaked, forcing them to audit and update roles for 10-15 million people :)

by philips 10y ago

willow9886 10y ago

> My only complaint is the name of OpenID Connect is simply confusing. Yea..many people only remember the failed OpenID 1 & 2 specs...so, out-of-the-box there is some developer fatigue associated with Connect. However, federation standards have proven to be pretty sticky--SAML was written 10+ years ago. Hopefully as Connect continues to be developed, marketed, and implemented by developers, it will over shadow previous unsuccessful versions of the protocol.

philips 10y ago
I have just started saying OIDC as that has no fatigue attached to it. And then if people want clarification I explain the whole silly naming story.
user5994461 10y ago
Don't confuse OpenID and OpenID Connect. They are very different things.
- pyvpx 10y ago
  with very similar names?
  - user5994461 10y ago
    They shouldn't have had similar names. This is causing a lot of confusion ^^
    - nailer 10y ago
      OpenID has a bad enough reputation amongst developers - with the user being asked to remember bizarre URLs - that I'm surprised they kept the name.
idm_guru 10y ago
It's no more confusing then LDAP. First there was LDAP 1.0, 2.0, now we all use 3.0... OpenID 2.0 is deprecated. Don't use it. The current OpenID authentication protocol = OpenID Connect. In the not too distant future, no one will even remember that something called OpenID 2.0 existed. Maybe OpenID Connect should be OpenID 3.0? I think the idea was to show alignment with Facebook Connect's design...but more open. Remember, at the time Facebook Connect provided some good data--it was a massive user acceptance test. IMHO, the blame lies with the OIDF for not delivering this message. OpenID Connect has been final for 4+ years. What's taking so long? Maybe it's not in the interest of the OIDF's controlling board members to promote this distributed identity infrastructure? MSFT wants you to use Azure AD. Google wants you to use their IDP. Maybe they don't want to promote until they have product ready? Stay tuned... I think when it's in the interest of the current finanical backers of the OIDF to promote OpenID Connect, no one will remember that old OpenID 2.0 thing.
WorldMaker 10y ago
There's also a flipside too: those of us that remember the original community grassroots spirit and attempted simplicity of early OpenID and feel like OpenID Connect misses a lot of the old point of OpenID, and definitely a lot of the intended simplicity.

philips 10y ago

And as if to prove my point LWN just ran an article on OpenID https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/ https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/

willow9886 10y ago
This is maddening! OpenID Connect is not an extension of OpenID 1 & 2--it is basically a complete re-write!

spangry 10y ago

When I did a short 6 month stint at the Australian version of the GDS (the 'Digital Transformation Office', or DTO), my team stood up a prototype/demo of an attributes-based 'digital identity' system using OIDC. It's almost ideal for the government use-case: private sector IDCs can offer identity/attribute verification services if the government provides an assurance and audit framework. The potential number of digital commercial transactions this could enable are mind-boggling. It's also privacy-preserving due to its attributes-based approach to access control and its federated nature. Also likely to result in a competitive market for IDCs instead of YAGM (yet another government monopoly) due to the low (technical) barrier to entry: I'm a terrible programmer and I spent less time coding a mock RP/client implementation straight from the spec than I did searching around for pre-canned libraries (which didn't seem to exist at the time). It's a shame no-one would listen to us. From what I hear, they're going with some kind of centralised RBAC system. Boy it's going to be fun when some welfare payment or tax concession eligibility criteria is tweaked, forcing them to audit and update roles for 10-15 million people :)