OAuth vs JWT

The question is an common one, but it isn't quite sensible. JWT is a type of Token, and OAuth is a Framework that describes how to dispense tokens. JWT can absolutely be used as an OAuth Bearer token. In fact, this is the most common practice. In light of that "JWT vs OAuth" is a comparison of apples and apple carts.

Often people think "OAuth token" always implies an opaque token that is granted by a OAuth token dispensary, that can then be validated only by that same OAuth dispensary system. But this is not the only kind of OAuth token. JWT is just a different kind of OAuth token.

Today, the OAuthV2/GenerateAccessToken policy in Apigee Edge generates opaque tokens. It returns a token of 32 seemingly random characters, and the holder has no idea what the token signifies. Therefore, we call it "opaque". To USE the token, the holder must present it back to the token dispensary, because the original dispensary is the only party that can relate the opaque string to meaningful information. You can think of an opaque token as a pointer to information that is held only by the token dispensary.

JWT, in contrast are not opaque. The JWT is not a "pointer" or reference to information. It actually contains lots of information, that can be extracted and interpreted by any party that has the token. Because the JWT contains real information, a JWT can be large; 300 bytes or more, depending on the claims contained within it. When people say "JWT are self-validating" what they mean is, any holder of the JWT can open it, validate it, and then make authorization decisions based on the claims presented in it. Validating the JWT means: verifying its structure, decoding the base64 encoding, verifying the key is correct, verifying the signature, then verifying the required claims are present in the token, checking the expiry. It's not a simple thing, rather a multi-step process, but the point is, any holder could theoretically do that with the token. Because of this, we say that JWT supports "Federation" - anyone can generate a token, and anyone can read and validate a token.

What are the places you'd want to use opaque tokens versus JWT?

Use JWT when...

• Federation is desired. For example, you want to use Azure AD as the token issuer, and then use Apigee Edge as the token validator. With JWT, an app can authenticate to Azure AD, receive a token, and then present that token to Apigee Edge to be verified. (Same works with Google Sign-In. Or Paypal. Or Salesforce.com. etc)
• Asynchrony is required. For example, you want the client to send in a request, and then store that request somewhere, to be acted on by a separate system "later". That separate system will not have a synchronous connection to the client, and it may not have a direct connection to a central token dispensary. a JWT can be read by the asynchronous processing system to determine whether the work item can and should be fulfilled at that later time. This is, in a way, related to the Federation idea above. Be careful here, though: JWT expire. If the queue holding the work item does not get processed within the lifetime of the JWT, then the claims should no longer be trusted.

Use opaque tokens when...

• There is no federation. The issuer of the token is the same party that validates the token. All API requests bearing the token will go through the token dispensary.
• There is no need or desire to allow the holder of the token to examine the claims within the token.
• When you wish to unilaterally allow token revocation. It is not possible to revoke JWT. They expire when they are marked to expire at creation time.

Things that DON'T recommend one versus the other:

• custom claims. Both JWT and opaque OAuth tokens can carry custom claims about the subject.
• security. Both are bearer tokens. Both need to be protected as secrets.
• expiration. Both can be marked with an expiration. Both can be refreshed.
• The authentication mechanism or experience. Both can present the same user experience.

There are situations where you'd use a JWT for something OTHER than a traditional bearer token, For example, RFC7523 explains how to implement something like a client_credentials grant (as described in OAuth v2.0 RFC6749), but rather than sending in a base64 encoded payload with id:secret, the client sends in a self-signed JWT. To make this happen the client needs to sign with HMAC 256, or the client needs to have a public/private keypair provisioned in place of the traditional "client secret". You can read more about RFC7523 in Apigee Edge, here.