I have explained the Flow of OAuth 2.0 in the previous post. In Step C – Request Access Token, I mentioned that the client requests an access token from the Authorization server using the Authorization grant received in step B.
Access tokens can have different formats and structures. The bearer token is one of the access tokens.
Video tutorials help in better learning. You must watch the video below. But it is always a good practice to read and understand the articles as well.
Bearer Tokens are the predominant type of access token used with OAuth 2.0. A bearer token is an opaque string. It is not possible to understand or read through the bearer token. The client is not supposed to extract any information about the resource owner from the bearer token.
Below is an example of the bearer token –
Bearer ya29.a0AVvZVso2p6SPMtqPpVA4xvqiULI5Jf_J5Xm0J8YiKOuXZfDqon7b0hW8hI8R0_4oREs534aJsa2hPEWf4193STMx3uY7h54HhZfQa93X87PDorglSxW67QmW29Smh-Q3OLcvQ8wC_SgB75UDB_6JFLXSf5-nyojOaCgYKAYUSAQASFQGbdwaIsRDrmFSwqNjQSnttGfEYew0167
It is called a bearer token or bearer authorization as it implies “Fulfill the request made by the bearer of this token on successful validation”. For example – If a resource owner has authorized a client to upload a file on Google Drive then the client needs to represent the bearer token i.e. access token with the Google Drive API to upload a file in the resource owner’s Drive.
As per RFC 6750, there are three methods to send bearer access tokens in resource requests to resource servers. Clients must not use more than one method to transmit the token in each request.
The client can pass the bearer token in the “Authorization” header as part of the request headers. An example is given below –
The client adds the access token to the request body using the “access_token” parameter with the Content-Type header as “application/x-www-form-urlencoded”.
The client adds the access token to the request URI using the “access_token” parameter.
Thanks for reading. Kindly comment for any feedback and suggestions.