Bearer Token authentication and JWT

0
votes

I've been provided with a REST API which has authentication type bearer (Security Scheme Type: API Key, Header parameter name: Authorization) and which i use to authenticate the user and then fetch other data (i will only create the front end using react).

As a first step the user logs in and i sent his/her username-password to the prementioned REST API and get back an access and a refresh token.

Is anything wrong with storing these 2 tokens in a cookie in order to use them in subsequent requests? How does JWT comes into play regarding these 2 tokens? Is JWT of any use to me in this situation?

2
reactjsjwtbearer-token
Is the REST API which was provided to you a third party api? Do you have control over the REST API such as changing its function handler? - kayuapi_my
I do not have control over the REST API. - Professor Chaos
Is the REST API you mentioned in the first paragraph and the api you mentioned in the second paragraph the same? I am confused by your question because there are identity providers which provides REST API access for the devepers to obtain access and refresh token for the clients, such as in the case of third party logins. - kayuapi_my
Yes they are the same - Professor Chaos

2 Answers

2
votes

There's nothing wrong in storing the tokens in cookies, but if you're planning to have a Single Page Application with React it should be enough to store these tokens in memory. Once the user refreshes the page you can either make them sign in again or perform a silent login in the background to get a new set of tokens. In both cases the session kept on the Authorization Server should kick in and you should get new tokens without the need of user interaction.

Your tokens will be much safer if you don't keep them in cookies.

JWTs are not a requirement for access and refresh tokens. If you don't have to use them I would recommend going with opaque tokens. That said, since you do not have control over the API you might be limited to the format required by the API. If you don't want to be limited by this format you can set up your own gateway which you can use to perform token exchange or introspection and forward requests to the API with proper tokens (something which is called a Phantom Token pattern.

0
votes

From my understanding of the question, you are using an identity provider which provides you with access token and refresh token for the users. That means it is a authentication as a service REST API at works here.

The REST API requires an authorisation header to be passed along with the username-password to exchange for access token and refresh token for the users. (correct me if I'm wrong) In this case, you might want to keep the authorisation header away from the users (consult the authentication as a service documentation).

You call the REST API with payloads (the user-password) along with headers like this:

Authorization: ACCESS_TOKEN

However the ACCESS_TOKEN is the one provided by the vendor for you to use the REST API. On success call of the REST API, it should return you with a set of access token and refresh token. You can then use this access token and refresh token to safe guard your own API, API that you control to provide service to your users.

The access token and refresh token might just be JWT tokens (again consult the vendor documentation).

Also if you are using an authentication as a service REST API, check the documentation if they provide a client sdk. In that case, it should show you the best practise of handling the access token and refresh token it returned.