What's the difference between JWTs and a Bearer Token?

Question

I'm learning something about Authorization like Basic, Digest, OAuth2.0, JWTs, and Bearer Token. JWTs are used as an Access_Token in the OAuth2.0 standard. JWTs appears at RFC 7519, and Bearer Token is at RFC 6750.

For example, the Bearer:

Authorization: Bearer <token>

I used to send token to server by AJAX or add token to the query string of the URL. I know that a token can also be sent by adding it to a request header. Does that mean that token should be added to Authorization Bearer header?

What is the relationship between JWTs and a Bearer Token?

Leicestershire

Related Q/A (mentioned in one of the answers below): What are Bearer Tokens and token_type in OAuth 2? – Pentadactyl

Answer 1

JWT is an encoding standard for tokens that contains a JSON data payload that can be signed and encrypted.

JWT can be used for many things, among those are bearer tokens, i.e. a piece of information that you can present to some service that by virtue of you having it (you being the "bearer") grants you access to something.

Bearer tokens can be included in an HTTP request in different ways, one of them (probably the preferred one) being the Authorization header. But you could also put it into a request parameter, a cookie or the request body. That is mostly between you and the server you are trying to access.

Monro

Then how to parse the token in Authorization header, there is a Bearer , I have to use String.slice(), is there any middleware to parse it? – Leicestershire

I'm using Node.js – Leicestershire

Use the auth-header package if you want a minimal parser – Malayopolynesian

Or just use String.slice() :) – Viscounty

I beg your pardon, sir after some years but what secret key? If the secret key is just one, it is ok. But what if we have some companies with which we share our API with different secret key for each one? What should we do? Should we store the secret keys in Db? If so, db relation still exists. Doesn't it? – Scrap

use string.split(" ") – Kopple

Answer 2

Short answer

A JWT is a convenient way to encode and verify claims.

A Bearer Token is just a string, potentially arbitrary, that is used for authorization.

Context (story time)

A few years ago, before the JWT revolution, a <token> was just a string with no intrinsic meaning, e.g. 2pWS6RQmdZpE0TQ93X. That token was then looked-up in a database, which held the claims for that token. The downside of this approach is that DB access (or a cache) is required everytime the token is used.

JWTs encode and verify (via signing) their own claims. This allows folks to issue short-lived JWTs that are stateless (read: self-contained, don't depend on anybody else). They do not need to hit the DB. This reduces DB load and simplifies application architecture because only the service that issues the JWTs needs to worry about hitting the DB/persistence layer (the refresh_token you've probably come across).

Katelin

Thanks, and how about Mac in Authorization, are the Mac and Bearer the same? – Leicestershire

Best answered elsewhere, e.g.: dzone.com/articles/oauth-20-bearer-token-profile – Katelin

I beg your pardon, sir after some years but what secret key? If the secret key is just one, it is ok. But what if we have some companies with which we share our API with different secret key for each one? What should we do? Should we store the secret keys in Db? If so, db relation still exists. Doesn't it? – Scrap

Answer 3

The value of an Authorization header in a request contains a value that can be used by the server to authorize the request.

The header comes in the following format:

Authorization: <auth-scheme> <authorization-parameters>

Where the auth schema tells us what type of value is set as a parameter.

There are several types of schemas defined, here are some examples:

• Basic
• Bearer
• Digest

There is a more complete list here.

So bearer is an authentication schema.

Bearer tokens can come in different formats. A JWT is one format of a token, another type of token format is called an opaque token.

A JWT is a base64 encoded Json formatted string, containing a header section, a body section and lastly a signature section. In this type of token you can add different claims, which are claiming certain things (like the username, email address, what roles etc)

While an opaque token is just a random unique string, that is opaque that doesn't contain any additional information.

JWT tokens and opaque tokens are different bearer token formats.

How they are used, and when to use each, is a huge discussion; there are good and bad usages. But both of these are usually used when implementing oauth2, but there are several other user cases.

I have seen JWTs been sent in bodies to just send signed data. So to be really honest a JWT is just a format of some data. It does not necessarily need be a token.

Forename

Answer 4

Since you mentioned that you send tokens in your URL query parameter this might be interesting for you. I think sending them as URL parameters, like you and some other answers mentioned might lead to some security issues. you should always use the Authentication header in your HTTP request, like recommended in the following RFC Doc. RFC6749 Use Access Tokens

As far as I know, bearer is just a more generic term for tokens, because in the following RFC7523 it's also often referred to JWT Bearer Token. However it is true that in contrast to the "normal" Bearer Token the JWT also holds information (about the issuer, creation date, ...) in, as the name implies, when decoded the JSON Format. Note that this parameters can be decoded by anyone, so this shouldn't include sensitive data, unless encrypted. JWT just ensures that the data sent inside the token, isn't manipulated because of the signature which consists of

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

with the secret either a passphrase or public/private key pair. In the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is. The size of the payload of a JWT should not exceed approx. 8kB because some browser won't accept tokens of this size. For further information about JWT you can either look up JWT.io or for more detailed information RFC 7523 JWT for oAuth

Some other information I gathered from RFCs contributing to this topic confirm my assumptions, very interesting stuff here:

Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option. Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option.

Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers MAY support this method.
https://www.rfc-editor.org/rfc/rfc6750#section-2.3

Bearer Token
A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
https://www.rfc-editor.org/rfc/rfc6750#section-1.2

Brooklime