
OAuth vs. SAML vs. OpenID Connect - willow9886
http://www.gluu.co/oauth-saml-openid
======
philips
> 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-
conne...](http://kubernetes.io/docs/admin/authentication/#openid-connect-
tokens)

~~~
willow9886
> 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.

~~~
user5994461
Don't confuse OpenID and OpenID Connect.

They are very different things.

~~~
pyvpx
with very similar names?

~~~
user5994461
They shouldn't have had similar names. This is causing a lot of confusion ^^

~~~
nailer
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.

------
clintonb
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.

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.

~~~
ve7jtb
Have a look at: [https://github.com/juanifioren/django-oidc-
provider](https://github.com/juanifioren/django-oidc-provider)

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

~~~
clintonb
This project is a great OIDC provider, but a not-so-great OAuth 2.0 provider.
For example, it doesn't support the client credentials grant type.

------
scwoodal
Having recently been apart of a new SAML implementation, avoid it if you can.

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.

------
spydum
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 _authentication_ of a user (that is just up to the identity provider).

~~~
willow9886
True, perhaps worth noting though that in OpenID Connect an RP (website or
app) can actually request a specific authentication mechanism using the
acr_value (assuming the OP supports multiple authentication mechanisms). This
can give the application some input over how people are identified before
authorizing access to protected resources.

[http://openid.net/specs/openid-connect-
core-1_0.html#acrSema...](http://openid.net/specs/openid-connect-
core-1_0.html#acrSemantics)

------
willow9886
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.

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

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

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

~~~
willow9886
New blog published on this topic specifically:

[http://gluu.co/jwt-not-authn](http://gluu.co/jwt-not-authn)

------
djedipus
In defense of SAML for enterprise customers.

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.

------
koliber
I can only speak to OAuth and SAML. I've done many integrations of each.

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.

~~~
_nat
OIDC can act just like SAML. It can contain the attributes (we call it claims)
as well. You do not need a backend call at all if you use implicit flow.

------
fusiongyro
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.

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.

~~~
vertex-four
CAS is definitely useful for internal authentication - you have a database of
users and a pile of apps. It's really easy to hack CAS authentication into
almost any web app, and you can write a custom server if you like.

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.

~~~
fusiongyro
I know, but you wind up doing what you're told to do even if it is stupid
sometimes.

------
tscs37
I was a bit skeptical when I first heard about OpenID Connect, especially
considering the failures of the first OpenID protocols.

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.

------
willow9886
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:
[https://www.linkedin.com/in/nynymike](https://www.linkedin.com/in/nynymike)

------
chris_wot
SAML is freaking hard to setup, and even worse to troubleshoot.

------
vittore
Anyone here knows of solid FOSS alternatives to gluu? Is there is something
that is close to okta functionality-wise?

~~~
willow9886
> that is close to okta functionality-wise?

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.

~~~
chris_wot
OneLogin... you mean like the guys who can't setup SSL Certs correctly?

[https://www.pinterest.onelogin.com](https://www.pinterest.onelogin.com)

~~~
cyberpunk
That seems a bit harsh, it's a wildcard cert on onelogin.com and they have a
'catch all' DNS on there which will break ssl for anything above that:

[https://massive.bag.of.dicks.pinterest.onelogin.com](https://massive.bag.of.dicks.pinterest.onelogin.com)

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

~~~
chris_wot
The fact they have a "catch all" DNS resolver for an SSL-based website that is
an interface for admins and end users alike that is guaranteed to fail says a
lot about their ability to sell a secure product.

~~~
cyberpunk
And how else would you let your users have a subdomain login url? Why bother
generating specific certs and dns for each when you can just use the HOST
header for the login and use a wildcard?

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

I mean:

[https://bigger.bag.of.dicks.signin.aws.amazon.com/](https://bigger.bag.of.dicks.signin.aws.amazon.com/)

~~~
chris_wot
Because those Certs weren't designed for this scenario.

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.

~~~
cyberpunk
This was designed for exactly that sort of scenario. If you're runnin a SAAS
then this is totally common practice, it's used by at least AWS, Slack, and
GitHub off the top of my head.. Are you saying these companies are doing
something stupid?

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

------
misja111
When I try to open the link, it gives me the error "Error opening database
connection"

~~~
willow9886
Sorry! DB crashed. It's back up. Thanks for alerting!

------
intrasight
I'm a fan of auth0 since it can glue all that identity stuff together.

