In the SAML and Kerberos authentication models, there is an explicit understanding of what authority has authenticated the user and issued the credential to be trusted by downstream systems. For purposes of identity propagation, the rights of the downstream system to impersonate the user can be tightly controlled within the solution architecture and the associated identity domains.

As far as I can tell, the completeness of the SAML and Kerberos models is not part of the JWT approach. JWT appears to be a mechanism that provides functionality quite similar to Kerberos, but without the supporting functionality of a defined KDE.

Am I missing something? Is JWT based on a "web of trust" or is each JWT implementation responsible for defining its own trustable authentication mechanism and so on?

1 Answer 1


So, a JWT is just a token. It's not a protocol. As such you really can't compare the SAML protocol to a JWT as that would be like comparing apples to ducks.

A JWT is just a bunch of identifying information signed by a cryptographic key. What you actually put in it is up to the protocol. There are some formal requirements that distinguish a JWT from a JWS object like issuer and audience information, but that information is still arbitrary. Comparatively SAML tokens and Kerberos tickets do have a bit more structure to them, but that's not to say you can't add the same information to a JWT.

Protocols on the other hand are a bit trickier to compare.

The two protocols people generally think about are OAuth2 and OpenID Connect. Both can and do use JWTs as their token. OAuth2 often uses JWTs as an authorization mechanism -- the presence of the JWT and the claims in the JWT determine what sort of permissions the caller has against a protected resource. It has nothing to do with identifying the user. Conversely a protocol like WS-Federation uses SAML tokens by default to provide identifying information about the user, but can use JWTs as drop in replacements (so long as all parties understand the format) because you can put the same information into the JWT body.

  • In this case, maybe I'm comparing a duck to a bill. The duck's bill is an important component, but without a number of other components you don't have a viable beast! That was really the point I was getting at with this question. JWT isn't a solution and building the pieces that would constitute a complete solution is a lot of our-of-scope work for most development efforts. Thanks for the answer, you have confirmed my impression, which is what I needed. [Don't let me get started on OAuth2! IMO, it is a poorly written framework, rather than a protocol, but hey, that's just me!] Oct 12, 2015 at 20:05
  • @JaimeCastells ah well, analogies lose meaning too easily. You're not wrong -- JWT isn't a solution on its own. BUT as a part of bigger solution they are WAY more useful than (say) SAML tokens because of simplicity and portability.
    – Steve
    Oct 12, 2015 at 20:23

You must log in to answer this question.

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