Article summary
My current project at AO has provided a lot of opportunity to learn about web security and what’s going on when you click that ubiquitous “Sign in with Google/Facebook” button. As both a computer developer and an end user, I want applications that are secure without being too difficult to use.
Looking for an option to fit both our application and our customer’s security policies, we investigated OpenID, OAuth2, and SAML.
Authorization & Authentication Basics
Our project, a single-page application, will be a public-facing website. We want to restrict access to registered users only. Furthermore, we want to tailor each user’s experience, and the amount and type of data that they can view, to their individual roles and access levels.
In other words, we want to be able to authenticate and authorize each user. Authentication means verifying that someone is indeed who they claim to be. Authorization means deciding which resources a certain user should be able to access, and what they should be allowed to do with those resources. Oftentimes, as in our case, an application will require a little bit of both.
With sites like Facebook or Google, a user can log in to one application with a set of credentials. This same set of credentials can then be used to log in to related websites or applications (like websites that ask you, “Sign up with Facebook or Google account?”).
Likewise, a business may have an internal-facing employee portal with links to intranet sites regarding timesheets, health insurance, or company news. Rather than requiring an employee to log in at each website, a better solution would be to have the employee log in at a portal, and have that portal automatically authenticate the user with the other intranet sites. This idea, called single sign-on (SSO), allows a user to enter one username and password in order to access multiple applications.
The benefits are pretty nice for the user. The use of linked identities means they have to manage only one username and password for the related websites. The user experience is better for them, as they can avoid multiple logins. A user’s (single set of) credentials will be stored in one database, rather than multiple credentials stored across multiple databases (with, let’s be honest, likely repeated passwords). This also means that developers of the various applications don’t have to store passwords. Instead, they can accept proof of identity or authorization from a trusted source.
There are multiple solutions for implementing SSO. The three most common web security protocols (at the time of this writing) are OpenID, OAuth, and SAML. Implementations and libraries exist in multiple languages already, and going with a standardized protocol allows better interoperability than a custom solution.
OpenID
OpenID is an open standard for authentication, promoted by the non-profit OpenID Foundation. As of March 2016, there are over a billion OpenID-enabled accounts on the internet, and organizations such as Google, WordPress, Yahoo, and PayPal use OpenId to authenticate users.
A user must obtain an OpenID account through an OpenID identity provider (for example, Google). The user will then use that account to sign into any website (the relying party) that accepts OpenID authentication (think YouTube or another site that accepts a Google account as a login). The OpenID standard provides a framework for the communication that must take place between the identity provider and the relying party.
This exchange can be compared to a border crossing. Imagine that Alice is a Canadian citizen who wants to visit the US. At the border, the US asks for proof of identity (her passport). Because the US government trusts the Canadian government to accurately provide identification for its citizens, the US accepts Alice’s passport as reliable proof of her identity, and thus, lets her enter the US. In this example, Alice is the end user, the US is the relying party, and Canada is the identity provider.
This exchange works because Alice can provide proof of identity to the US that originates from an entity that the US trusts. Similarly, the relying party (or website that a user is trying to log in to) must trust the OpenID identity provider that will verify the user’s identity.
On a website, the exchange looks like this:
Let’s return to Alice, who wants to log in to her MyBlogger account (the relying party). She navigates to the login screen, where she is offered a “Sign in with Google” option. She clicks that, and MyBlogger initiates association with Google and requests and receives an association handle. MyBlogger then forwards Alice to the Google login page. She enters her credentials, and Google validates them. She is then redirected back to MyBlogger, along with a token stating that Google believes she is who she claims to be (Alice). MyBlogger trusts this token and creates a session for her.
Notes:
- OpenID is technically a URL that a user owns (e.g. alice2016.openid.com), so some websites offer the option to manually enter an OpenID.
- The latest version of OpenID is OpenID Connect, which combines OpenID authentication and OAuth2 authorization
- Facebook previously used OpenID but has since moved to Facebook Connect.
OAuth2
By contrast, OAuth2 is an open standard for authorization. Confusingly, OAuth2 is also the basis for OpenID Connect, which provides OpenID (authentication) on top of OAuth2 (authorization) for a more complete security solution. OpenID Connect (OIDC) was created in early 2014. This primer will instead focus on OAuth2 by itself, not as a part of OIDC.
OAuth2 provides secure delegated access, meaning that an application, called a client, can take actions or access resources on a resource server on the behalf of a user, without the user sharing their credentials with the application. OAuth2 does this by allowing tokens to be issued by an identity provider to these third-party applications, with the approval of the user. The client then uses the token to access the resource server on behalf of the user.
Yet Twitter’s OAuth guide says that OAuth2 is an authentication standard. So what gives? As it turns out, authorization can be used as a form of pseudo-authentication.
An authorization use case of OAuth2 might be as follows: Alice is leaving town and she wants her friend Bob to house-sit. Alice gives Bob the house key, and he now has access to enter the house. The key gives him authorization to enter the house, as authorization relates to which resources a user should have access to, and what they can do with those resources. In this metaphor, the homeowner is the user, Bob is the client, the door lock is the identity provider, and the house is the resource server.
This can be twisted into a pseudo-authentication use case by assuming that the person who has the house key is the homeowner. However, as we can see with Bob house-sitting for Alice, this is not always the case.
Online, an OAuth2 use case might look like this: Alice signs up for a new account at NewApp and is offered the option to see which of her friends already use NewApp so she can connect with them. There’s a button labeled “import contacts from Facebook.” Alice clicks that button, and she is redirected to Facebook to log in. Alice successfully logs in and is asked if she wants to share her Facebook friend list with NewApp. She clicks yes, and is forwarded back to NewApp along with a token. NewApp now has permission (with the token) to access Alice’s friend list, without her sharing her credentials directly with NewApp. This eliminates the risk of NewApp logging into Facebook on Alice’s behalf and doing things she wouldn’t want (posting status updates, changing her password, etc.).
SAML
SAML is the oldest standard of the three, originally developed in 2001, with its most recent major update in 2005. SAML, pronounced “sam-el,” stands for Security Assertion Markup Language. It’s an open standard that provides both authentication and authorization.
Similar to the terminology of the other two standards, SAML defines a principal, which is the end user trying to access a resource. There is a service provider, which is the web server that the principal is trying to access. And there is an identity provider, which is the server that holds the principal’s identities and credentials.
The US/Canada metaphor can be used here, as well. Alice wishes to enter the US from Canada. The US, wishing to verify her identity or other information about her–perhaps whether she has a valid driver’s license that will allow her to drive in the US)–makes a request to Canada for authentication and/or authorization information regarding Alice. Canada responds by sending the requested information to the requested address, along with some proof that Canada was indeed the sender of the message. All metaphors break down eventually, but this proof might take the form of a passport, as before, or official government documents or visas (where authorization requests are involved). And, as before, the system is predicated on US trust that Canada is issuing driver’s licenses, visas, etc. properly.
In our example, Alice is the principal, the US is the service provider, and Canada is once again the identity provider. The request made to Canada by the US is analogous to an XML message that states what information is being requested, who is asking, and to whom the response should be returned. Canada’s response would be called an assertion, in SAML terms (similar to a token for OpenID or OAuth2). This assertion can contain statements about authentication, authorization, and/or attributes (specific information about a user, such as email or phone number).
The SAML 2.0 specification defines assertions (as discussed above); protocols, which are assertion requests and responses; bindings, or how these requests and responses happen between the service provider and identity provider, using standard communication methods (e.g. HTTP POST); and profiles, which are combinations of assertions, protocols and bindings for various use cases, like SSO.
An SSO use case might look like this: Alice is a manager at Acme Corp. She accesses Acme Corp’s intranet portal, where she logs in with her credentials. After logging in, she can click on a number of links that may be of interest to her (payroll, company news, Salesforce, etc.). She clicks on the Salesforce link, which contains a SAML assertion about Alice. She is forwarded to Salesforce, which receives the SAML assertion. Salesforce trusts Acme Corp, and thus trusts the assertion. Using information in the token, Alice is automatically logged in, and the appropriate data is shown to her based on attributes in the assertion.
Summary
These three options are summarized in the table. Our application implements IdentityServer, a .NET framework that implements both OAuth2 and OpenID Connect.
OAuth2
|
OpenId |
SAML
|
|
Token (or assertion) format
|
JSON or SAML2
|
JSON
|
XML
|
Authorization?
|
Yes |
No
|
Yes
|
Authentication?
|
Pseudo-authentication
|
Yes
|
Yes
|
Year created
|
2005
|
2006
|
2001
|
Current version
|
OAuth2
|
OpenID Connect
|
SAML 2.0
|
Transport
|
HTTP
|
HTTP GET and HTTP POST
|
HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others
|
Security Risks
|
Phishing
OAuth 2.0 does not support signature, encryption, channel binding, or client verification. Instead, it relies completely on TLS for confidentiality.
|
Phishing
Identity providers have a log of OpenID logins, making a compromised account a bigger privacy breach
|
XML Signature Wrapping to impersonate any user
|
Best suited for
|
API authorization
|
Single sign-on for consumer apps
|
Single sign-on for enterprise
Note: not well suited for mobile
|
Great summary of all auth*-standards!
Why, in your opinion, is SAML not well suited for mobile?
Thanks Simon. I wrote that SAML isn’t well suited for mobile because SAML recommends using an HTTP POST binding for sending assertions (when the Identity Provider posts the token/assertion back to the Service Provider to log a user in), and native apps don’t have access to the HTTP POST body. Here’s a blog post from Mutually Human that’s more in-depth and shows some workarounds. The SAML/mobile section is about 1/3 of the way down the page. https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
Thanks Jaime. Great article!!
Can you please help us on below point?
1. Is SSO between Hybrid app and web page is possible?
2. Can we enable a SSO between two HYBRID MOBILE APPS?
Thanks Jaime for the article.SAML is little bit more complex compare OpenID Connect in terms of implementation. We also have few enterprise applications but instead of SAML we are also planning to use identity server for SSO. Any Gotcha, recommendations for Identity Server implementation?
A few things come to mind:
-Any user claims you want included in a token must be specified both on the user, and in the scope that you are trying to access (under Scope Claims).
-There were a number of times when some functionality we wanted already existed in a related project (IdentityServer.Admin, IdentityManager, IdentityServer.EntityFramework, etc.). The two biggest examples for us were out-of-the-box user creation/management, and programmatically modifying a user with the UserManager.
-Read into different workflows and use cases when you set up your clients and scopes, as the Type and other settings vary based on what you’re trying to do and won’t work otherwise.
-You need the ‘offline access’ scope for refresh tokens to work.
Hopefully some of those items will help you, but there’s enough variety in use cases for IdentityServer that it might not overlap your needs. On the plus side, there are numerous example projects and a lot of resolved issues on their GitHub. Good luck!
Jaime,
Great article. I was wondering about a few things:
1. You summarize that IOpen ID doesn’t offer Authorization. Is that for OpenID 2.0? Does OpenID Connect offer Authorization?
2. Why didn’t you evaluate Facebook Connect?
3. A lot of companies offer a choice of login– offering a variety of solutions like Facebook Connect, Twitter Connect, signup with an email… none of these options provide at all the same infos (authentication/autorization) so how to best make sense of multiple-login?
Thanks for the article Jaime! This was pretty helpful!
But it seems like there is no difference between Open ID and SAML.
How can we differentiate both methods using the US/Canada example (if possible)?
Superb and Excellent
Thanks for the article Jaime! This was pretty helpful!
HI Jaime Lightfoot,
this is the one of the best article i ever seen..thank you for sharing such a wonder full article ..
Please keep on do …
Jaime,
Amazingly well-written and crystal clear on the basics! Thanks for this piece.
Hey Jaime,
while researching on a sso topic i found your article and i need to say that its a really good one. The whole topic is bloated with different terms for the same things but you found a fine way to describe the three protocolls and their differences.
anyway, i have a question or maybe a misunderstanding about the term authorization in sso and i hope someone can solve it ^^.
In the user context authorization means to give a user acces to a ressource. in server-based applications you could do this with in database-stored lists of rights and/or roles for example. same for hybrids but i don’t really know how to do it with real SPA’s. In my Opinon this has nothing to do with SSO.
in the oauth (and maybe sso?) context authorization means giving a client (a website) access to resource an behalf of a user. For example the client has access to my facebook friendlist.
Does authorization in sso stands for giving rights to a user or giving rights to a application? or… ehm both? does it depend? ^^
best regards,
andy
Giving rights to the user who’s browser signed into the SSO site. We are dealing with design issues in an app of ours because SAML assertions for authenticated users do not provide the information/security we need to *authorize* inter-application API requests made on behalf of the user. OAuth2 is definitely the solution for authorization when making app-to-app requests on behalf of users. Especially when transmitting username and password is not an option.
I love a good real world analogy and the border control example here is excellent.
Thanks for putting this together Jaime – I found it incredibly useful.
A very good knowledge share article, excellent!
OAuth2 is for Delegation !! not authorization or authentification
Nice article! We also just posted a blog discussing the differences and similarities between these three protocols: http://www.gluu.co/oauth-saml-openid
Nice presentation, thanks
Hi Jaime, great description, thank you for that,
I would like to ask if SAML can work for desktop applications as well ?
thank you
No SAML is for web only.
The best summary of the protocols I’ve yet read, many thanks!
Hi ,
Great article, however I would like to get one thing clarified, as per my understanding
Federated Identity management : – SAML, OAuth and OpenID
Single-sign-on – Kerberos.
I just think both were confused, however I may be wrong. Kindly enlighten me!
Great article. Helped me to get clarity on SAML and OAuth2.0
Thanks
Very interesting blog and great introduction to these key technologies and concepts. So many people use these terms interchangeably and you helped clarify the distinction for me.
Jaime, first of all great article, going to help me big time, but I am still confused with the role of JWT token and do see it been mentioned anywhere in your article, can you please help me understand that as well where does it fit in the picture and whats the diff between SAML Assertion and JWT assertion.
Thanks for posting. It is very well explained. Congratulations!
Dear Jamie, this is wonderfully clear.
I have one additional question: we want people to login to our family of websites by creating one central identity on our main website. What is the best way to become an identity provider ourselves? Or does one of the protocols above solve that?
Yo continue your example, if you would create a second website, you would want people to create a central ID on your first one? Or alternatively, create a super ID that links I to all?
Thanks!
Thanks, nice post
Jamie
This is an Awesome article, with details on all 3 major authentication models.
Thanks
Sreedhar
Great article! I mean Great. Thanks for this!
Good article, will read this again as I’m still new to the OAuth and OpenID world. But your article sure spells out clearly. Just have to embed these in my mind.
Great article!
Perhaps you can clear a related question since you are so good at explaining!
In looking into OAUTH2 I see there are scopes and there are claims … It seems that scopes are more generic and claims give more granularity … Would you agree with this? Perhaps you can expand or explain when one would use each one?
aTdHvAaNnKcSe !!!
C
(thanks IN advance)
Very well written. Thank you
This is a brilliant summary Jaime. Thanks vey much for that.
Many thank you!
It details and, well written and clear.
Indeed a great article on SSO. Keep up with good work!
Awesome post, really easy to understand without being incomplete.
Best article I’ve seen on the subject so far! The analogies really helped. Thanks!
Very well articulated. Thanks a lot!
Still reading and finding it useful in 2018! I especially like the examples on border control. I have one quesiton (same as another poster). You summarised that Open ID does not offer authorization. I assume this is no longer the case for OpenID Connect which is built on OAuth 2.
Could you clarify?
Yes, reading after tons of sites to get a clarity on protocol, framework, oauth, openid, SAML, I was getting no where and in fact more confused. Great and pretty clear write up! Keep up the great work.
I see many examples for OpenID/OAuth, would you recommend any site with example for SAML implementation.
This is really well written article providing overview and comparison of authentication & authorization protocols. You really know how to explain things.
Though one question, is SAML token format and protocol both (unlike to JWT, which is just token format)?