Gluu Blog

Follow us:
Back to Blog

JWT is NOT an authentication protocol

Michael Schwartz December 15, 2016

JWT - JSON Web Token - Authentication

Many developers who are lukewarm about OAuth 2.0 feel that JWTs (JSON Web Tokens) offer a compact, stateless alternative for authentication.

Defined in RFC 7519, JWTs provide a mechanism for sending a JSON object that is optionally signed, and optionally encrypted, as one very compact, url-safe string.

The JWT includes up to three components: a header (which describes the signature algorithm); a payload (which has the data); and a signature (optional).

With some frequency I hear comments to the effect of: “I’d rather use JWT access tokens than OpenID Connect.” Or, “I’d rather use JWTs because they are simpler and stateless.”

But how would a client obtain this JWT? Wait a second, what is a client?

And if the JWT is signed, where do you get the public key needed to verify it?

How do you provide the public key used to encrypt it?

And what if my client is a browser based JavaScript client? Or a mobile application?

I could probably fill this entire blog with potential questions one could ask about the circumstances surrounding the use of JWTs… Which is not to say JWTs are not great!

JWTs are way cool, and they are used extensively in the OpenID Connect specification.

In OpenID Connect, the id_token, request object, and Userinfo response are all JWTs.

But of course, JWT is just a part of the solution.

Wanting to use JWT instead of OpenID Connect is like wanting to use a SAML assertion without the SAML protocol.

After all, a SAML assertion (a signed XML) is just a stateless bearer token (especially if it’s just signed and not encrypted).

What makes an authentication protocol secure are the mechanisms to protect the request and response.

For better or worse, browser redirects are used to sign-in at a remote identity provider (both SAML, OpenID Connect and “plain” OAuth). There are many places where a system based on redirects can be attacked by malicious parties.

To protect against these attacks, OpenID Connect–building on the infrastructure laid out by OAuth–includes certain security features.

For example:

  • how do you know the JWT in the response relates to the request you sent? Connect defines the nonce.
  • How do you know that the access token has not been modified? Connect defines the at_hash.
  • How do you know the code has not been modified? Connect defines the c_hash.
  • How do you securely send the request?
  • How does your client register a public key, to use private key authentication to access the token endpoint?

Connect fills in the gaps for all these questions.

So yes, the puck is moving towards JWT… but that’s like saying the puck is moving towards JSON/REST!

If you are using OAuth to authenticate a person, and you are using JWT, then you will have to define a lot of details to do so securely. Instead of making up your own recipe (which you probably don’t have the time to do…), leverage the best practices defined by some of the world’s leading security nerds.

Making up your own protocol is risky. Most developers don’t build in the security protections necessary. They just “get it working” and move on–until their site gets hacked. Then they contribute to giving OAuth a bad name. Also, regarding client registration… there is not much client metadata specified in OAuth 2.0.

Check the IANA registrations for OAuth, and what you’ll see is that Connect defines more IANA OAuth parameters than OAuth itself.

So if you love JWT, and you are OK with OAuth, check out OpenID Connect–it provides the missing pieces that many people need to use JWT to define a secure sign-in flow for web and mobile applications.

If you are using OpenID Connect, and you need to tell the backend microservice which user you are calling it on behalf of, pass the access token. This is what the access token was designed for. The microservice can use the access token to call the OpenID Connect Userinfo endpoint. Now your stateless wishes can come true!

Why wouldn’t you want to pass the id_token JWT? There are a two reasons: (1) the audience of the id_token is not the microservice; (2) if encryption is used, the microservice would not be able to decrypt it (it would not have the private key if asymmetric encryption is used, or it would not have the client secret if symmetric encryption was used). 

Be sure to subscibe to
our RSS Feed

Mike Schwartz

Mike has been an entrepreneur and identity specialist for more than two decades. He is the technical and business visionary behind Gluu. Mike is an application security expert and has been a featured speaker at RSA Conference, Gartner Catalyst, Cloud Identity Summity (now "Identiverse") and many other security conferences around the world.