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.
JWT: JWT RFC published in 2014. JWT is much newer.
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.
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.
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).
SAML2: XML (structure defined with XSD)
JWT: JSON (interestingly, structure is NOT defined by JSON Schema)
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
SAML2: XML Signature
JWT: JWS (supported hashing and encryption algorithms differ slightly)
SAML2: XML Encryption
JWT: JWE (supported encryption algorithms differ slightly)***
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.
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