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