254

According to RFC6750-The OAuth 2.0 Authorization Framework: Bearer Token Usage, the bearer token is:

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.

To me this definition is vague and I can't find any specification.

  • Suppose I am implementing an authorization provider, can I supply any kind of string for the bearer token?
  • Can it be a random string?
  • Does it have to be a base64 encoding of some attributes?
    Should it be hashed?
  • And does the service provider need to query the authorization provider in order to validate this token?
SecretAgentMan
  • 2,856
  • 7
  • 21
  • 41
Alex Beaupré
  • 2,670
  • 2
  • 14
  • 8
  • Suppose I am implementing an authorisation provider, can I supply any kind of string for the bearer token? Can it be a random string?. Access Tokens are issued via Auth0's OAuth 2.0 endpoints: /authorize and /oauth/token. You can use any OAuth 2.0-compatible library to obtain Access Tokens. If you do not already have a preferred OAuth 2.0 library, Auth0 provides libraries for many languages and frameworks. – Bharathkumar V Apr 08 '18 at 14:09

6 Answers6

212

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).

The Bearer Token is created for you by the Authentication server. When a user authenticates your application (client) the authentication server then goes and generates for you a Token. Bearer Tokens are the predominant type of access token used with OAuth 2.0. A Bearer token basically says "Give the bearer of this token access".

The Bearer Token is normally some kind of opaque value created by the authentication server. It isn't random; it is created based upon the user giving you access and the client your application getting access.

In order to access an API for example you need to use an Access Token. Access tokens are short lived (around an hour). You use the bearer token to get a new Access token. To get an access token you send the Authentication server this bearer token along with your client id. This way the server knows that the application using the bearer token is the same application that the bearer token was created for. Example: I can't just take a bearer token created for your application and use it with my application it wont work because it wasn't generated for me.

Google Refresh token looks something like this: 1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copied from comment: I don't think there are any restrictions on the bearer tokens you supply. Only thing I can think of is that its nice to allow more than one. For example a user can authenticate the application up to 30 times and the old bearer tokens will still work. oh and if one hasn't been used for say 6 months I would remove it from your system. It's your authentication server that will have to generate them and validate them so how it's formatted is up to you.

Update:

A Bearer Token is set in the Authorization header of every Inline Action HTTP Request. For example:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

The string "AbCdEf123456" in the example above is the bearer authorization token. This is a cryptographic token produced by the authentication server. All bearer tokens sent with actions have the issue field, with the audience field specifying the sender domain as a URL of the form https://. For example, if the email is from noreply@example.com, the audience is https://example.com.

If using bearer tokens, verify that the request is coming from the authentication server and is intended for the the sender domain. If the token doesn't verify, the service should respond to the request with an HTTP response code 401 (Unauthorized).

Bearer Tokens are part of the OAuth V2 standard and widely adopted by many APIs.

Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
  • Let me rephrase my question: Suppose I am implementing an authorisation server, are there restriction for the bearer tokens I will supply ? – Alex Beaupré Sep 15 '14 at 13:15
  • 1
    @Freerider brearer token is valid until the user removes it Access token is only good for around an hour in most cases. – Linda Lawton - DaImTo Sep 15 '14 at 13:46
  • 1
    @AlexBeaupré I don't think there are any restrictions to the bearer tokens you supply. Only thing I can think of is that its nice to allow more then one. For example a user can authenticate the application up to 30 times and the old bearer tokens will still work. oh and if one hasn't been used for say 6 months I would remove it from your system. Its your authentication server that will have to generate them and validate them so how its formatted is up to you. – Linda Lawton - DaImTo Sep 15 '14 at 13:48
  • Thanks DalmTo, so it would simply be out of scope of the OAuth 2.0 specification and would be left to the implementation. If you have time to include this comment in your answer, I'll mark this as answer. – Alex Beaupré Sep 15 '14 at 23:01
  • @DaImTo So, for you Bearer Tokens = Refresh Tokens? – Xavier Egea Sep 16 '14 at 20:42
  • A colleague of mine pointed me to the proper part of the specification: The client accesses protected resources by presenting the access token to the resource server. The resource server MUST validate the access token and ensure that it has not expired and that its scope covers the requested resource. The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. – Alex Beaupré Sep 23 '14 at 16:45
  • @DaImTo how can i generate single token per user? every time i send request for one user it give me different token – AminM Jan 30 '17 at 10:49
  • 2
    @ Xavier Egea Bearer token is basically your refresh token and not the access token . – Akhil Nambiar Sep 07 '17 at 06:02
  • 1
    If the bearer token is the refresh token, then is that the same as the `Bearer ...` in the `Authorization` header? My understanding was that the *access token* is sent in requests from an authenticated user and not the *refresh token*. – Web User Dec 26 '17 at 15:17
  • can some one clearify about its difference with jwt token – Ahmed Nawaz Khan Aug 16 '18 at 19:15
  • Actually it should be sufficient if the authentication server signs the token instead of encrypting it. In the case of single sign on systems might be even a strict requirement to use asymmetric cryptography, since the authentication server must not expose its private key to the resource servers. Therefore a breach in one resource server does not affect the authentication server or the other resource servers. – Mike76 Sep 25 '18 at 16:31
  • @DaImTo Can you please define "cryptographic token". Honestly, I do not know what "a cryptographic token" is. Did you intend to use "a security token". Also, [RFC6749](https://tools.ietf.org/html/rfc6749#section-1.5) does not mandate use of any function (cryptographic or not) to create a security token. A token (an identifier) is just a string representing the authorization granted to the client by the resource owner. – Elis Byberi Oct 12 '18 at 19:54
  • 25
    Bearer token doesn't mean its a refresh token @AqeelSmith https://tools.ietf.org/html/rfc6750#section-6.1.1 – Suman Kundu Oct 16 '18 at 09:50
  • 21
    The first paragraph implies that a Bearer token is a refresh token and not an access token. This is not the case. From the Bearer token spec "This specification describes how to make protected resource requests when the OAuth access token is a bearer token." [RFC6750](https://tools.ietf.org/html/rfc6750) – Daniel Nov 13 '18 at 04:43
  • 13
    After reading the answer, I also thought Bearer token and refresh tokens are the same. The answer should be updated to clarify this. – KurioZ7 May 22 '19 at 04:18
  • Apparently according to RFC6750 linked by @SumanKundu above, the bearer token should include **both** the access token and the refresh token? – xji Aug 05 '19 at 14:12
  • 1
    Section 5.1 of RFC6749 specifies the format of a successful response ( https://tools.ietf.org/html/rfc6749#section-5.1). Based on that you can conclude that: refresh token is optional, both the JSON response returned by the server and the value of its 'access_token' property are referred to as Access Token which can be confusing. The response content is actually a wrapper object containing at the very least the Access Token and the Token Type. Depending on the value of 'token_type' parts of that response can be used as a Token suitable for a Bearer authentication scheme. – Andrea Scarcella Aug 08 '19 at 12:09
  • 2
    access tokens have a short lifetime, while refresh tokens are comparatively valid for a longer duration.we use access tokens to access any resource on a server side,but when access tokens expire we use refresh tokens to generate a new access token,so that you don't have to give your password everytime the access tokens expire. but when the refresh tokens expire you have to give your username and password but thats a long enough period say a month. – Mahesh Jamdade Sep 03 '19 at 11:39
  • 8
    This answer is very misleading. Bearer tokens are NOT Refresh Token, as the initial statement of this answer states. Please correct. – think01 Oct 11 '19 at 16:23
  • 5
    @think01 done. What a difference five years makes in your understanding of something. – Linda Lawton - DaImTo Oct 16 '19 at 11:26
96

As I read your question, I have tried without success to search on the Internet how Bearer tokens are encrypted or signed. I guess bearer tokens are not hashed (maybe partially, but not completely) because in that case, it will not be possible to decrypt it and retrieve users properties from it.

But your question seems to be trying to find answers on Bearer token functionality:

Suppose I am implementing an authorization provider, can I supply any kind of string for the bearer token? Can it be a random string? Does it has to be a base64 encoding of some attributes? Should it be hashed?

So, I'll try to explain how Bearer tokens and Refresh tokens work:

When user requests to the server for a token sending user and password through SSL, the server returns two things: an Access token and a Refresh token.

An Access token is a Bearer token that you will have to add in all request headers to be authenticated as a concrete user.

Authorization: Bearer <access_token>

An Access token is an encrypted string with all User properties, Claims and Roles that you wish. (You can check that the size of a token increases if you add more roles or claims). Once the Resource Server receives an access token, it will be able to decrypt it and read these user properties. This way, the user will be validated and granted along with all the application.

Access tokens have a short expiration (ie. 30 minutes). If access tokens had a long expiration it would be a problem, because theoretically there is no possibility to revoke it. So imagine a user with a role="Admin" that changes to "User". If a user keeps the old token with role="Admin" he will be able to access till the token expiration with Admin rights. That's why access tokens have a short expiration.

But, one issue comes in mind. If an access token has short expiration, we have to send every short period the user and password. Is this secure? No, it isn't. We should avoid it. That's when Refresh tokens appear to solve this problem.

Refresh tokens are stored in DB and will have long expiration (example: 1 month).

A user can get a new Access token (when it expires, every 30 minutes for example) using a refresh token, that the user had received in the first request for a token. When an access token expires, the client must send a refresh token. If this refresh token exists in DB, the server will return to the client a new access token and another refresh token (and will replace the old refresh token by the new one).

In case a user Access token has been compromised, the refresh token of that user must be deleted from DB. This way the token will be valid only till the access token expires because when the hacker tries to get a new access token sending the refresh token, this action will be denied.

Chris Sharp
  • 2,005
  • 1
  • 18
  • 32
Xavier Egea
  • 4,712
  • 3
  • 25
  • 39
  • 3
    I don't understand this part: "Once the Authorization Server receive an access token, it will be able to decrypt it and read these user properties. This way, the user will be validated and granted along all the application". Isn't authorization server the one that grants access token, not receive it? I'm trying to get my head around this subject and a lot of examples makes a clear distinct between Authorization server and Resource server. What I have understood is that you get Access token from Authorization server and then pass it along with every request that you make to the resource server? – kivikall Oct 10 '17 at 11:33
  • 1
    @kivikall You are right. I've changed it in the answer. The Resource Server receives the token (The token that the Authorization Server has encrypted in the token creation process) in every request and decrypts it. – Xavier Egea Oct 14 '17 at 18:10
  • 1
    @kivikall Actually, to decrypt a token should be something related to the authorization, so it should belong to the Authorization Server. That's why a wrote it in the answer. But in practice, this would mean that in every request you have to validate with the Authorization Server the token received (maybe performing another request). So, to avoid loss of performance, it's better to give some of the functionality to decrypt the token to the Resource Server. Check the next link: https://stackoverflow.com/questions/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server – Xavier Egea Oct 14 '17 at 18:10
  • 1
    But on every request the Resource Server should check if the provided AccessToken is valid against the Authorization Server. So if a role changes the change can be reflected immediately by the Auth Server, right? Also why would we delete the RefreshToken if the AccessToken was compromised? The RefreshToken cannot be calculated based on the AccessToken, so when it expires the hacker is blocked again. – mandarin Dec 05 '18 at 09:41
  • As I said, the access token contains user information, like the role. If a user role changes, this change will be reflected in the next token when the current token expires. This means that in a short period of time (till access token expiration) the user will mantain the same role and the Auth Server will allow it because the token is still valid. Regarding the second question, deleting a Refresh Token makes the user insert their credentials again. This is what we want if an access token is compomised. In other case, a hacker can be authorized till the refreshtoken expiration (for ex.1 month) – Xavier Egea Dec 05 '18 at 09:58
  • Apparently according to RFC6750 linked by @SumanKundu above, the bearer token should include **both** the access token and the refresh token? https://tools.ietf.org/html/rfc6750#section-4 – xji Aug 05 '19 at 14:12
  • @xji If the access token is valid and authorized a refresh token SHOULD NOT be included. https://tools.ietf.org/html/rfc6749#section-4.4.3 – Xavier Egea Aug 07 '19 at 13:50
  • 1
    "An Access token is an encrypted string". Encrypted or encoded ? – Tarun Aug 10 '20 at 11:13
  • 1
    Am I correct to understand that the word "Bearer" in the context is similar to how it is used in "Bearer check": "a check that is considered to be owned by the person who has it in their possession, rather than by a named person." So, "The bearer of this token shall be considered as authorized to do things listed in claims in the token"? – Ivan Koshelev Dec 31 '20 at 15:06
  • What to stop a hacker getting access to a long lived Refresh Token and using that to retrieve new Access Tokens? – Cathal Mac Donnacha Apr 29 '21 at 12:30
  • @Tarun is right: tokens are encoded and signed, not encrypted. The Resource Server should validate the signature and expiration date/time of the token presented. – GLRoman Sep 16 '21 at 04:45
  • @XavierEgea: the refresh token isn't returned for grant type = "client credentials". It *IS* returned for most other grant types. – GLRoman Sep 16 '21 at 05:15
  • @IvanKoshelev: yes, the bearer (client) is authorized to assume the included roles/scope on behalf of the user for a limited period of time. – GLRoman Sep 16 '21 at 05:19
12

Bearer token is one or more repetition of alphabet, digit, "-" , "." , "_" , "~" , "+" , "/" followed by 0 or more "=".

RFC 6750 2.1. Authorization Request Header Field (Format is ABNF (Augmented BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

It looks like Base64 but according to Should the token in the header be base64 encoded?, it is not.

Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token.

This fully addresses the first 3 items in the OP question's list. So I'm extending this answer to address the 4th question, about whether the token must be validated, so @mon feel free to remove or edit:

The authorizer is responsible for accepting or rejecting the http request. If the authorizer says the token is valid, it's up to you to decide what this means:

  • Does the authorizer have a way of inspecting the URL, identifying the operation, and looking up some role-based access control database to see if it is allowed? If yes and the request comes through, the service can assume it is allowed, and does not need to verify.
  • Is the token an all-or-nothing, so if the token is correct, all operations are allowed? Then the service doesn't need to verify.
  • Does the token mean "this request is allowed, but here is the UUID for the role, you check whether the operation is allowed". Then it's up to the service to look up that role, and see if the operation is allowed.

References

Community
  • 1
  • 1
mon
  • 18,789
  • 22
  • 112
  • 205
  • 3
    You are not explaining at all the purpose of Bearer tokens. – Jaime Hablutzel Apr 28 '20 at 22:14
  • 2
    This is the best and by far the clearest answer. If you look at the OP question, it answers at least 3 out of the 4 bullet points if not all 4. The OP question was not about purpose, but about the contents of the token and (4th item in the list) whether it needs to be validated. – Oliver Feb 22 '21 at 21:51
  • 2
    @JaimeHablutzel, please read the questions (4 bullet points in the original question). Which one of four asks for "purpose of Bearer token"? I provided the answers to the bullet points 1 to 3. Please see the comment above by Oliver too, and please focus on "answering to the question". – mon Feb 23 '21 at 22:31
  • Does `1*SP` mean `1 space`? It took me over thirty minutes to work that out – byxor Apr 02 '21 at 12:34
  • @byxor, it is from the RFC. Perhaps it is a common convention in IETF. – mon May 14 '21 at 10:54
12

Please read the example in rfc6749 sec 7.1 first.

The bearer token is a type of access token, which does NOT require PoP(proof-of-possession) mechanism.

PoP means kind of multi-factor authentication to make access token more secure. ref

Proof-of-Possession refers to Cryptographic methods that mitigate the risk of Security Tokens being stolen and used by an attacker. In contrast to 'Bearer Tokens', where mere possession of the Security Token allows the attacker to use it, a PoP Security Token cannot be so easily used - the attacker MUST have both the token itself and access to some key associated with the token (which is why they are sometimes referred to 'Holder-of-Key' (HoK) tokens).

Maybe it's not the case, but I would say,

  • access token = payment methods
  • bearer token = cash
  • access token with PoP mechanism, e.g. MAC token = credit card (signature or password will be verified, sometimes need to show your ID to match the name on the card)

About the term "Bearer"

"Bearer check(cheque)" refers to a type of check that is not named or endorsed. It can be cashed or deposited by anyone who physically possesses the check, as it does not require any specific identification or authorization. While for "name check", also known as order check, refers to a type of check that is specifically made payable to a named individual or organization. In order to cash or deposit a name check, the payee must present proper identification and endorse the check by signing the back of it. The payee's endorsement serves as authorization for the bank to process the check and transfer the funds to the named individual or organization.

Anderson
  • 2,496
  • 1
  • 27
  • 41
7

A bearer token is like a currency note e.g 100$ bill . One can use the currency note without being asked any/many questions.

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).

ekhanad
  • 154
  • 2
  • 8
2

The bearer token is a b64token string, with the requirement that if you have it, you can use it. There are no guarantees as to what the meaning of that string actually is in the specification beyond that. It is up to the implementation.

5.2. Threat Mitigation

This document does not specify the encoding or the contents of the token; hence, detailed recommendations about the means of
guaranteeing token integrity protection are outside the scope of this document. The token integrity protection MUST be sufficient to
prevent the token from being modified.

https://datatracker.ietf.org/doc/html/rfc6750#section-5.2

While the token could be random each time it is issued, the downside is the server side would need to keep track of the tokens data (e.g. expiration). A JSON Web Token (JWT) is often used as a bearer token, because the server can make decisions based on whats inside the token.

JWT: https://jwt.io/

Wrexbe
  • 29
  • 1