SAML2 vs JWT: A Comparison

This post concludes our discussion of SAML2 and JWT. Here we look at a comparison of the features and use cases of the two technologies. It’s difficult to make a direct comparison of JWT and SAML2. As we’ve seen through this series, one must take into account the specifications that work in conjunction with these specs.

For JWT, we must consider:

For SAML2, we must consider

The following summarizes the key differences between SAML2 and JWT. The original version of this post used a table format, but Medium.com doesn’t support tables.

Age

SAML2: SAML 1.0 introduced in 2002; SAML2 introduced in 2005.

JWT: JWT RFC published in 2014. JWT is much newer.

Adoption

SAML2: SAML2 is the defacto-standard for Enterprise SSO. It has been for a while now.

JWT: JWT, OAuth2, and OpenID Connect are common in the Social Media and tech startups, but is only now finding its way into the enterprise.

Philosophy

SAML2: More academic approach. Simplicity was not a design goal. There was an assumption that runtime libraries would be developed to implement this functionality.

JWT: Simple. Started with the assumption that the application developer would implement the client-side code. As the specs matured and the enterprise adoption occurred, the community started moving away from this.

Token Types

SAML2: SAML Assertion (format strictly defined by specs)

OAuth2: access_token (can be JWT, but doesn’t have to be)

OIDC: access_token (can be JWT) and id-token (must be JWT).

Data Structure

SAML2: XML (structure defined with XSD)

JWT: JSON (interestingly, structure is NOT defined by JSON Schema)

Size

SAML2: Tend to be very large in comparison to JWT. Size varies depending on what fields are present, use of Signatures and Encryption.

JWT: Much smaller than SAML2 tokens. Spec encourages use of reference to signature certificate rather than embedding it — eliminates large x509 signer cert.

Supporting Messaging Protocols

SAML2: Largely SOAP-based.

JWT: REST APIs

Bindings and Transport Protocols

SAML2: SAML2 can be HTTP POST, HTTP GET, SOAP(depends on scenario), JMS(rare, but could happen), etc

JWT: HTTPS

Digital Signatures

SAML2: XML Signature

JWT: JWS (supported hashing and encryption algorithms differ slightly)

Message-Level Encryption

SAML2: XML Encryption

JWT: JWE (supported encryption algorithms differ slightly)***

X509 Certificate representation

SAML2: X509BinarySecurityToken type

JWT: JSON Web Key spec (JWK)

Core Spec scope

SAML2: Defines structure of token (SAML Assertion) and underlying protocol (for Web App SSO).

JWT: JWT defines only the token structure. OAuth2 and OpenID Connect define the protocol.

Client-side infrastructure

SAML2: Generally requires supporting libraries (heavy-weight)

JWT: Often can be implemented by constructing a simple HTTP query. Signatures and Encryption would be exceptions to this rule.*

Subject Confirmation Method support

SAML2: SAML2 supports Bearer Tokens, Holder of Key, and Sender Vouches.

JWT: JWT supported Bearer Tokens only, originally. Holder of Key (Proof of Possession support added in April, 2016).

Delegation & Impersonation (OnBehalfOf and ActAs)

SAML2: Defined in WS-Trust spec

JWT: Extension spec of OAuth2 (OAuth2 Token Exchange Spec)

Support for dynamic truststore updates and publishing of meta-data information.

SAML2: WS-Federation spec defines how this information can be published. But, it is not universally used. It is rare for clients to dynamically retrieve information published by an IdP to update its signer cert truststore.

JWT: OpenID Connect Discovery specification defines a meta-data endpoint that publishes IdP meta-data. It is strongly encouraged to construct clients that can access this information and dynamically build/update the truststore.**

*Using libraries is almost always advisable over building queries/requests from scratch.

**This one detail can potentially save 1000s of man hours when the signer certificate must be renewed.

***JWE and XML Encryption will have a number of relevant differences as well, but I haven’t gotten to that series yet:).

All the differences outlined in the XML DSig vs. JSON Web Signature Seriesalso apply here.

Image: Lock & Key / Kyle Pearson