What are the differences between JSON Web Tokens, SAML and OAuth 2. Please provide some pointers and high level overview of their functions.

Specifically, why would one use SAML over JSON Web Tokens or viceversa? Does one need to have OAuth 2 to use JSON Web Tokens/SAML? Or can JSON Web Tokens/SAML be used independently?

  • 2
    Very simple, not complete and maybe a bit wrong: SAML is (only) for single sign on in the web. OAuth2 lets you delegate access to certain clients - usually let an App access a service without providing the the originial credentials. JWT is a way to handle authentication on websites instead of cookies and sessions.
    – cornelinux
    Feb 26, 2015 at 22:42
  • Jadiel and cornel would you mind getting involved in discuss.area51.stackexchange.com/questions/21958/… ? thanks! Oct 1, 2015 at 23:16

1 Answer 1


SAML and OAuth 2 are protocols used in authentication/authorization. JSON Web Tokens (JWT) is a specification for a token that can be used in many applications or protocols - it happens that the OpenID Connect (OIDC) protocol uses the JWT. SAML also defines its own token: SAML Assertion; as does OAuth 2: Access Token. Tokens used by these protocols denote you have been authenticated/authorized and convey information about you or the session.

| Protocol | Token          | Technologies | Design Pattern |
| SAML     | SAML Assertion | SOAP, XML    | Facade         |
| OAuth 2  | Access Token   |              | Proxy          |
| OIDC     | Access Token,  | REST, JSON   | Decorator      |
|          | ID Token (JWT) |              |                |

The software design patterns associated with each of the protocols in the table above summarizes in one word what these protocols were intended to accomplished.

SAML. The Facade pattern provides a unified interface to a set of interfaces in a subsystem. SAML is the original federated identity system, invented by universities to allow students to access other university libraries, but each university maintaining their own student identity system. De facto standard in most enterprise environments. Built around XML and SOAP.

OAuth 2. The Proxy, much like its name suggests allows clients access to your information as if they were a proxy for you.

OIDC. Extends OAuth 2 by adding user ID and user info to the protocol. Often regarded as a modern version of SAML. Widespread use in the consumer space - almost all social media sites support OIDC. Built around JSON and REST.

Hopefully, this untangles your questions a little. You can't quite compare SAML (protocol) with JWT (token), but you can compare SAML with OIDC. You could however compare a SAML Assertion with an OIDC JWT. The OAuth 2 specification does not specify the underlying structure of its tokens. You might also find it interesting that OIDC can consume the SAML Assertion as well as its own JWT.

The consensus is that OIDC will eventually supplant SAML, but SAML has been around since 2005 and is very mature - an important trait in enterprise environments. Even though OIDC is relatively new (2014), authentication solutions these days (2018) are expected to support it. SAML was designed in an era where Web browsers were dominant and has somewhat of an awkward time with Mobile or modern Web applications. OIDC on the other hand supports modern technologies such as REST and JSON that makes it much more accessible from applications these days.

However, OAuth 2, OIDC and SAML do not actually specify how authentication and authorization are done in the way those two terms are traditionally defined.

When you hear authentication you think of a login/password, or fingerprint, or passcode sent to your phone - none of these protocols cover these specifics, rather authentication is delegated to the identity provider (IdP). These protocols specify how you should be redirected to an IdP to get authenticated, and if successful how the tokens/assertions are returned.

OAuth 2 "authorization" deals with obtaining user consent, i.e. whether to give a service access to your information/data - it does not mean authorization in the access control sense. OIDC much like OAuth 2 also supports a means of obtaining user consent. While SAML supports user consent as well, it is not generally used within an enterprise/intranet environment.

Authorization (referring to the more traditional access control meaning) is also not in OAuth 2, OIDC and SAML specifications, but they allow for tokens to contain claims such as whether a user belongs to an administrator group, which client services can interpret however it likes.

OAuth 2, OIDC and SAML are great facilitators for different authentication and authorization (access control) schemes, but do not actually specify the actual underlying mechanisms.

UPDATE 9/5/2018. Updated for 2018.

UPDATE 4/26/2017. Fixed incorrect statement about SAML not supporting user consent - it does, but not widely used.

UPDATE 2/22/2017. Clarify authentication, authorization (access control), and user consent in response to user comment below.

  • 1
    i think OAuth 2 also accepts JWT, right? tools.ietf.org/html/rfc7523
    – TJCLK
    Feb 22, 2017 at 10:56
  • and openid connect combines openid(authentication) and Oauth (authorization). u said that openid connect can be compared with SAML. i guess u mean both of them will work on authentication and authorization?
    – TJCLK
    Feb 22, 2017 at 10:59
  • 1
    OAuth 2 specification does not cover how its access or refresh tokens are represented. Tokens are opaque to the client, which means the authentication service can define and use any type of token it wishes, including JWTs.
    – HTKLee
    Feb 23, 2017 at 2:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .