How to send Tokens from the server to the client?

Question

How to send Tokens from the server to the client?

Navigation

#1 by (7 votes)

16

I am creating an API, I use Token Authentication (JWT), I want this token to be valid for, say, 10 minutes, and, at each request, return a new Token, so the user will have access while active , if it is disconnected for a long time (more than 10 min), it will have to reauthenticate

The client must create two requests, one requesting the main resource (a user search, for example) and another for a new token? Or is it better that the backend always returns, in addition to the user search, a new token?

In the case of the second option, how to send this token? Pass as part of the body? Is there any specific HTTP header for this? Is there a problem in passing the token via Cookie?

I saw the use of a Token and Authorization header but I did not find anything official, just in blogs. I know the second one is used to pass the token from the client to the server, vice versa too?

The Token header does not appear in the MDN, nor in the unofficial Wikipedia

The Authorization header only appears for requests, that is, from client to server

http token http-headers

asked by anonymous 17.09.2018 / 22:51

1 answer

What are metadata in relation to HTML documents? How to sort list with complex object by one of its properties?

score 7 · Answer 1

The ideal is to have a feature that authenticates the client and retries a token to it.

As for the Token header I do not know it and I did not find any references to it, it's probably a custom header, I usually see this term associated with the token schema as a generic schema, other terms for the schema are Bearer and Basic only these two specify the token type.

As for the Authorization header, it is used only to pass the token from the client to the server.

Now, why is it better to have a resource that authenticates the cliete and return a token than the API itself delivers a token to the client when the token expires? Let's look at two scenarios:

In the first scenario a client authenticates and receives an X token . This X token is captured by a client B that uses it to make requests. After 10 minutes the token will turn off. When Client A makes a request to the server it will receive a new token (the Token Y ) and, likewise, when Client < > make a request will also receive a new token for it (the Token Z ). Logo , in this scenario, Client B even though he did not authenticate correctly (since he "stole" the token from Client A) a valid token for requests to the API provided by the API itself.

In the second scenario a client authenticates and receives an X token . This X token is captured by a client B that uses it to make requests. After 10 minutes the token will turn off. When Client A requests the server it will return with an error message and request that the client re-authenticate itself to receive a new token (the Token Y ) and , in the same way, the Client B will also receive a message requesting it to authenticate again. Logo , in this scenario, Client B can initially make requests to the API using the captured token of Client A but when this token expires it will lose accessing the API having to catch a new token.

Final Thoughts:

The 10 minute limit for a token is just used to force the client to re-authenticate whenever the token expires trying to ensure that the client still has access to the API and that an unauthorized client has access to the API by capturing tokens of authorized customers.
The client access token is almost always sent in the body of the response to the authentication request. This may sound insecure but if you are working on HTTPS this information will be encrypted.