> If you are writing a new application, use OpenID Connect–skate to where the puck is going!<p>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.<p>> OAuth2 was left generic so that it could be applied to many authorization requirements,<p>When we started developing Dex[1] we lovingly referred to OpenID as "OAUTH 2.0 with types".<p>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.<p>My only complaint is the name of OpenID Connect is simply confusing.<p>[1] <a href="https://github.com/coreos/dex" rel="nofollow">https://github.com/coreos/dex</a>
[2] <a href="http://kubernetes.io/docs/admin/authentication/#openid-connect-tokens" rel="nofollow">http://kubernetes.io/docs/admin/authentication/#openid-conne...</a>
The problem with OIDC (from my point of view) is the lack of good libraries for Python/Django projects. We ended up building our own atop the now-defunct django-oauth2-provider. Unfortunately, no one (myself and my company included) has committed to adding the functionality to the more-popular django-oauth-toolkit.<p>This has lead to our questioning the need for OIDC given that we can generate JWTs as access tokens. If the identity info is embedded in the access token, there is no need for the ID token and (more importantly) micro-services no longer need to check in with the authentication provider to validate bearer tokens.<p>I do like the discovery aspects of the OIDC protocol that make it easy to distribute public keys.
Having recently been apart of a new SAML implementation, avoid it if you can.<p>The technology behind it feels solid (passing signed/encrypted messages around) and using an Identity Provider like Active Directory is an easy choice but after that is where things get difficult.<p>The client support, at least in Python, is terrible and the resources to understand SAML are sparse. Everyone does something just a little bit different and there isn't much choice.<p>We have some Django applications that needed to be SAML aware. While I was able to finally able to make it work after two weeks (yikes!!) most of my problems resulted in bugs within the client.<p>SAML requests can have more than one signing/encryption certificate defined so when one certificate gets close to expiring you can add a second (or third...), let the first one expire then well behaved clients would automatically use the second one. Except when your client always grabs the first one and if the signing fails because the Idp signed the message with the other certificate and it doesn't try the second one =(<p>Then debugging errors is cumbersome. Always pasting XML snippets and x509 certificates into tools to view the actual messages. Google'ing the error messages with little to nothing out there.<p>Perhaps it's just a bad experience with a specific python module but given the complexity of SAML, little knowledge out there, I'd stick with CAS if given the choice. It might help the technology if whoever is behind it would maintain clients that adhere to the spec.
Great write up. Dealing with my own employer and the constant confusion around oauth vs OIDC vs JWT, and having to explain they aren't VS at all! They are all stacked on oauth itself, and don't really have much to say about the actual <i>authentication</i> of a user (that is just up to the identity provider).
There's been some discussion regarding the merits of using JWT's (JSON Web Tokens) instead of Connect. Mike added some clarification in the form of a comment on the blog.<p>I also added it here [1]. Feel free to join the discussion on the blog.[2]<p>[1] <a href="https://news.ycombinator.com/item?id=13134752" rel="nofollow">https://news.ycombinator.com/item?id=13134752</a><p>[2] <a href="https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#comment-3042980417" rel="nofollow">https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...</a>
In defense of SAML for enterprise customers.<p>I built an enterprise site that needed SSO to work for a number of different enterprises.<p>I tried 3rd party solutions, ping fedeate, Auth0, Azure etc. and these were nightmares to configure and get working.<p>Turns out it was way easier just to read the SAML RFC and handle the tokens myself.<p>SAML 2.0 is finally old enough that most enterprises support it.<p>So for me Enterprise SSO is a solved problem. For others having a hard time finding 3rd party plugins / services etc. I highly recommend whipping out the RFC and DIYing a solution. Only took me a couple of days. Far less than what I spent on other solutions.
I can only speak to OAuth and SAML. I've done many integrations of each.<p>OAuth is a bit easier to understand.<p>SAML is tougher to grasp. I think it is a terminology and flexibility thing. It seems like each vendor or implementation is using their own terms for the same things. SAML has many super configurable levers, but in reality people tend to use only one or two common variants.<p>SAML is nice that it does not require a direct access between the backends of the client system (SP, or service provider) and the identity provider. All data flows through the web browser. As long as the web browser can access the identity provider (often on a private network) and the client system, it can work.<p>As far as different people implementing SAML in different ways, it is absolutely true. Getting two systems to work together takes real effort. I've had similar, albeit less fatiguing, issues integrating OAuth. One system has exact redirect URLs; others have partial matching some; some require the redirect URL in each call, others in some; and then there's the case where human intervention is required to deliver data that would normally be sent to the redirect URL (Looking at you AWeber!). At least in the OAuth world, people call a duck a duck and it is usually clear what is being referred to.<p>I'm by no means an expert in SAML (like with general relativity, I think there are only five people in the world that truly understand SAML), but have a good working practical grasp of the technology.
Interesting. I have used CAS extensively and was involved in building SAML support for a commercial app at one time. I didn't understand the post-binding thing really at all--CAS mostly uses the back channel method.<p>My experience with SAML was that, not only was it a bear to get set up, the second client who wanted to use it was using a different SAML implementation and found things weren't as standardized as we had assumed. Both implementations supplied a principal, only one supplied an email address by default. I think it got sorted out after I left.<p>I don't love CAS a lot, but it is a lot more turnkey than SAML.<p>We're investigating JWT now, but I have a feeling it will turn out to be an implementation detail within a larger solution that we haven't even begun to conceive.<p>I've also implemented shitty poor-man's federation on top of CAS. My recommendation there would be: don't do it. If you need federation CAS really can't help you, don't hack on it.<p>The other thing I've learned is that none of these things is going to help you with authentication at all, and that tends to be something that isn't well thought-out before implementation time comes.
I was a bit skeptical when I first heard about OpenID Connect, especially considering the failures of the first OpenID protocols.<p>I'm still looking for a decent OpenID server to run, but dex seems to be good enough.<p>I hope OIC catches on, I'd love some proper identity federation.
Thanks for all the upvotes everyone! If you'd like to connect with the author of the blog, Mike Schwartz, feel free to do so on LinkedIn: <a href="https://www.linkedin.com/in/nynymike" rel="nofollow">https://www.linkedin.com/in/nynymike</a>