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 [2] http://kubernetes.io/docs/admin/authentication/#openid-conne...

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 :)

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.

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.

They are very different things.

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.

I do like the discovery aspects of the OIDC protocol that make it easy to distribute public keys.

Feel free to continue the discussion in the comments section of our blog.[1]

" JWT's are great. That's why they are used extensively in the OpenID Connect spec. The question is what's in that JWT? What are the claims? How do you know that the JWT that you got back in the response relates to the request you sent (i.e. Connect defines the nonce)? How do you know that the access token has not been modified (i.e. Connect defines the at_hash)? How do you know the code has not been modified (i.e. Connect defines the c_hash). How do you securely send the request? How does your client register and obtain tokens?

So yes, the puck is going towards JWT... but that's like saying the puck is going to JSON/REST... If you are using OAuth2 to authenticate a person, and you are using JWT, then you will have to define a lot of details to do so securely. Instead of making up your own recipe (which you probably don't have the time to do...), leverage the best practices defined by the experts at Google and Microsoft. "

[1] https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...

If you need a license, just email [email protected] It's not free open source, but it will be very inexpensive. It reduces OpenID Connect to a simple three step process (with three corresponding method calls):

1. Get code 2. Get tokens 3. Get user_info

There are two more supporting methods:

4. Register client 5. Logout

I wrote a sample cgi-bin application (and there is also a sample Flask application) that shows how to use it. https://github.com/GluuFederation/oxd-python/tree/master/dem...

I know several Gov projects using it that are quite happy.

I think the main reason for that is that its not a simple thing to do and there's just not enough expertise out there.

https://github.com/gambol99/keycloak-proxy

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.

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.

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.

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 =(

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.

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.

http://openid.net/specs/openid-connect-core-1_0.html#acrSema...

I also added it here [1]. Feel free to join the discussion on the blog.[2]

[1] https://news.ycombinator.com/item?id=13134752

[2] https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...

http://gluu.co/jwt-not-authn

I built an enterprise site that needed SSO to work for a number of different enterprises.

I tried 3rd party solutions, ping fedeate, Auth0, Azure etc. and these were nightmares to configure and get working.

Turns out it was way easier just to read the SAML RFC and handle the tokens myself.

SAML 2.0 is finally old enough that most enterprises support it.

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.

OAuth is a bit easier to understand.

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.

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.

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.

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.

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.

I don't love CAS a lot, but it is a lot more turnkey than SAML.

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.

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.

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.

It's significantly less useful for external authentication - where you want to your apps to auth against other people's user databases. SAML 2.0 is usually the standard for that, but as you say, it has to be configured properly on both ends.

SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.

And the HTTP artifact resolution binding (a complete, start-to-finish, description of what you need to do to log in a user to SAML and get attributes about them) is in here: https://www.oasis-open.org/committees/download.php/56779/sst...

Those come from here: https://wiki.oasis-open.org/security/FrontPage

Frankly, though... you're usually not supposed to be implementing this stuff yourself. Put Shibboleth's mod_shib_24.so in Apache in front of your login endpoint, and it behaves as a SAML service provider for you with consistent configuration and lots of help available for when it breaks. It provides you with HTTP headers for all the attributes provided about the user. If you're not using Apache for most of your app, you could just use it for a login script which shoves everything into a cookie.

Of course, if you're developing ASP.Net for Windows, you get your sysadmin to throw up an ADFS instance which deals with the federation, then use the built-in libraries to auth against ADFS, and it all works like magic.

It will help you a bit. Then you will only have two majors issues.

1) The protocol is a really complex beast of giant XML messages, with many variants of workflows.

2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example.

I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.

I'm still looking for a decent OpenID server to run, but dex seems to be good enough.

I hope OIC catches on, I'd love some proper identity federation.

The power of OKTA lies in its thousands of pre-configured SSO relationships. It's important to remember that each one was set up manually with a unique client ID and secret, metadata file, etc.

Application integration is the most difficult part of most identity and access management projects. That is why outsourcing identity to a SaaS provider like OKTA or OneLogin is so appealing--they have done all the hard work for you.

There are no open source projects like OKTA because if you're using open source software, you will inevitably have to integrate and test each application you want configured for SSO.

https://www.pinterest.onelogin.com

https://massive.bag.of.dicks.pinterest.onelogin.com

Is www.pt.ol.com linked from anywhere?

This is totally common and used in a lot of places..

I mean:

https://bigger.bag.of.dicks.signin.aws.amazon.com/

The fact that you can create that domain name to resolve is funny. I can think of a few phishing schemes I could use with this, if I were so inclined.

How could you phish github or aws by using their dns/cert setup as they intended it to be used?

If I'm wrong on the last point, please let me know, as I know a lot of people that will be very happy to find out!

also, you can use https://pintrest.onelogin.com ;)

Keeping those thousands of predefined integrations aside, do you know of any good combination of user-management/access-management/federated-access system beside GLUU?

There's also the open source KeyCloak project from RedHat. [2]

Also I believe Connect2ID is FOSS. [3]

[1] https://www.forgerock.com/

[2] http://www.keycloak.org/

[3] http://connect2id.com/

An IAM platform is many products integrated together, and operationally scalable to meet mission critical requirements. An OpenID Provider is just one element of an IAM platform!

Friends don't let friends OpenAM though, don't bother with WSO2 either. I'd do everything possible to make this someone else's problem, and if you absolutely have to do it in house then ping's the easiest I've worked with thus far.

Making a SSO, even with nice friendly software (hint: none of it is, it's really really complex and easy to fuck up, and the stakes are pretty high) is a horrible, horrible, experience and if you've been through it you'll probably never want to do it again.

I've done it twice, perhaps I was just unlucky but it'll take a lot to convince me that the smarter plan isn't just to outsource that whole requirement instead of trying to build it / OSS it in house. It's pretty generic and can be a 'black box' on your arch diagram, your time is probably better spent building business specific things instead...

If I was absolutely forced to pick something to run on prem for IDP/Fed/Entitlement, I'd get the pingidentity onsite and have them build it for me (trust me, this will be cheaper than trying to do it yourself even if their day rate makes your eyes bleed).

I'd quit before seeing the OpenAM mgt console again.

You would need to host it somewhere, but does full OIDC if you so choose and can integrate with your AD (or multiple).