Nowadays there is no need for stressing the importance of web applications security. Almost on a weekly basis, we hear about new security breaches, data leaks, and other security failures. Of course, web applications vulnerabilities are responsible only for some of them. Still it is not the reason for putting less effort into securing them.
Today I will walk you through the three most common security protocols – SAML, OAuth and OIDC. I will present their features and compare them. Then suggest when and why one of them may be a better choice then the others.
Let’s start by explaining the difference between the two most basic security concepts: Authentication and Authorization.
Authentication vs Authorization
The concepts of authentication and authorization are inseparably related to users and their desire to access particular resources.
- Authentication — is a process of proving your identity to security provider. The question here is “Who are you?”
- Authorization — is about proving that you have required roles/permission to access specific resources. The question here is, “What can you do?”
The difference in meaning between those two concepts will be crucial when I will start comparing protocols. Especially in the case of comparing OAuth with OpenID Connect.
Details of SAML
First of all, SAML is an abbreviation from Security Assertion Markup Language. It is an open standard for exchanging authentication and authorization information between interested parties. In particular, an identity provider and a service provider.
Created in 2002 by OASIS Security Services Technical Committee. It is the oldest one from the protocols discussed today. Since 2002 SAML has had two updates, one minor to version 1.1 in 2003 and one major to version 2.0 in 2005. As for now SAML 2.0 is an official standard adopted by OASIS.
There are four most important concepts in SAML. Most of them underwent significant changes between version 1.0 and 2.0:
- Security Assertions — facts that are used by service providers to make access-control decisions. They are written using XML syntax. We can differentiate three types of such facts: Authentication, Attribute, and Authorization decision.
- Protocols — describe how certain SAML elements (including assertions) are packaged within SAML request and response elements. Protocols give the processing rules that SAML entities must follow when producing or consuming these elements. Query is the most important type of SAML protocol. There are also three types of queries: Authentication, Attribute, Authorization decision. Till SAML 2.0 queries were the only protocols specified by SAML. SAML 2.0 introduced and described 6 new protocols.
- Bindings — a mapping of a SAML protocol message onto standard messaging formats and/or communication protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message. SAML 1.1 specified only one binding — the SAML SOAP Binding. SAML 2.0 brought a brand-new binding specification defining 6 different standalone bindings
- Profiles — describes in detail how assertions, protocols, and bindings cooperate to support a defined use case. The most important profile is the Web Browser SSO Profile. SAML 2.0 gave us many new profiles and the complete refactor of profiles, aimed to make them more flexible.
As you can see there were some significant changes between different versions of the SAML protocol. Diving deeper into the mystery we can notice that those changes were aimed to make SAML 2.0 more flexible than 1.1 or 1.0 versions. Be aware, because of the scope of these changes SAML 2.0 and 1.1 are not compatible.
Additionally, there is a standard called Identity Federation Framework. Created by The Liberty Alliance in 2003. Its current version is 1.2. SAML 2.0 designers used IFF as a base for their protocol. Despite that both protocols are not compatible with each other.
Details of OAuth
OAuth or Open Authorization is a protocol for authorization. Published by IETF (Internet Engineering Task Force) in April 2010 as RFC 5849. It provides clients with “secure delegated access” to server resources on behalf of a resource owner. It also specifies a process for resource owners to authorize third-party access to their server resources without providing credentials.
IETF introduced OAuth 2.0 in October 2012 in the form of RFC 6749. It was also the first and only major update of OAuth. As for now, OAuth 2.1 is in “in-progress” state.
Of course, OAuth 2.0 and 1.0 are not compatible, you did not expect that, did you?
Nowadays, this standard is the most common one. Some of the biggest companies like Facebook or Google use OAuth as their protocol of choice. Many of such companies use it as the only supported authorization protocol.
For example:
- All Twitter third-party applications must use OAuth since 31 August 2010.
- Facebook Graph API only supports OAuth 2.0.
There are four main concepts in OAuth:
- Resource owner — entity capable of granting access to protected resource. When the resource owner is a person, they are referred to as end-users.
- Resource server — server hosting the protected resources. Capable of accepting and responding to protected resource requests using access tokens.
- Client — application making protected resource requests on behalf of the resource owner and with its authorization.
- Authorization server — server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
The interaction and relations between Authorization Server and Client are the most important part of OAuth.
Details of OpenID Connect
OpenID Connect or OIDC is an authentication protocol based on the OAuth 2.0 specification. Created in 2014 is the youngest of protocols from today. It is also the 3rd generation of a tool called OpenID, which never became famous and widely used.
Its main goal is “making simple things simple and complicated things possible”. It allows clients to verify the end-user’s identity based on the authentication performed by an Authorization Server. Additionally, it exposes REST-like API enabling us to get basic information about the end-user.
OpenID Connect works by adding OpenID scope value in the OAuth Authorization Request. Information about the authentication performed is returned as a JWT and called an ID Token. The two most important building blocks of OpenID flow are:
- OpenID Providers (Ops) -> OAuth 2.0 Authentication Servers implementing OpenID Connect
- Relying Parties (Rps) -> OAuth 2.0 Clients using OpenID Connect
As a side note, I can give you a math equation for OpenID Connect:
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
Difference Between SAML, OAuth, and OpenID Connect
The Biggest Difference
SAML mainly looks like ready to work tool while both OAuth and OpenID Connect are more like specifications — describing particulars flows — which could be further implemented.
What is more, OpenID Connect is built atop OAuth while OAuth and SAML are independent from one another. Naturally, all three protocols are incompatible in any combination.
A notable difference here is that OAuth specification seems to be low on details and leaves a few important topics up to you when implementing your solution. This may lead to incompatible implementations of the same protocol so does not seem to be a particularly good idea. Fortunately, OpenID Connect filled some of those gaps.
Purpose
SAML is a standard for exchanging both authentication and authorization information between interested parties. While OAuth aims to provide a mechanism for authorization only.
Despite that in OAuth we can also achieve a thing called pseudo-authentication when we abuse authorization features to make authentication possible. To some extent this is exactly what OpenID Connect is doing but specification and process was changed to be more secure and less confusing.
The exact description of pseudo-authentication is out of the scope of this text. Here is the page where you can find more information.
OpenID Connect adds an authentication layer over existing OAuth specifications effectively providing both authentication and authorization possibilities.
Complexity of Usage
From my perspective as a software engineer SAML looks like the most complex to use and implement. Mostly because of the old-school approach to configuration — writing XML files and all the things related to protocols and bindings.
While in the case of OpenID and OAuth you use plain old HTTP and not so old JWT. I know that nowadays we have tools for everything. Still, there may be cases where you need to do some low-level checks and trust me, you do not want to fight with auto-generated XMLs in such situations.
On the other hand, OAuth itself does not provide authentication features. You will have to mix it with other protocols (can be quite problematic), or use pseudo-authentication (even more problematic).
Notable features
Firstly, all three protocols seem to focus on supporting SSO. I may add that SAML was the first (ever) framework design to provide cross-domain SSO.
Also, SAML allows us to integrate with tools like LDAP to “get” already defined user profiles. This feature is not included in the two other remaining protocols.
On the other hand, SAML seems not to be the best choice for securing mobile and SPA applications.
In fact, SAML is best suited for old-school applications with a traditional backend. It works this way mostly because of conceptual decisions taken years ago when such application types did not exist.
Maybe SAML 3.0 if it gets created (or when) will add some additional possibilities here.
Choosing the Correct Protocol
If you expect that I will provide you with a silver bullet solution for every case you will, unfortunately, be disappointed. As usual, I will give you some general guidelines and leave the final decision up to you.
First of all, if your application already uses SAML then go for SAML, any other mix will end with a headache.
If you want to have many interactions with Google, Facebook or Twitter then OAuth and OpenID will be best suited. Keep in mind that if you rely heavily on authorization then OAuth will be a better solution. While OpenID Connect would be better for authentication heavy integrations.
For mobile and SPA-type applications, OpenID Connect may be the best-suited protocol. However if you only want to secure your API the OAuth 2.0 may be a better option.
Summary
The guidelines above are a good summary of today’s text. I tried to stay as objective as possible and not favor any particular solution.
The final decision on choosing a tool to secure your application I leave up to you. Remember to think through this decision because it may not be the easiest one to revert. Thank you for your time.
Comments are closed.