How to send Tokens from server to client?

Asked

Viewed 1,019 times

17

I am creating an API, I use authentication via Token (JWT), I want this token to be valid for, for example, 10 minutes, and, with each request, return a new Token, so the user will have access while active, if disconnected for a long time (more than 10 min)you will have to re-use

Should the customer create two requests, one asking for the main feature (a user search, for example) and the other for a new token? Or it is better that the backend always returns, in addition to the search for users, a new token?

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

I saw the use of a header Token and of Authorization but found nothing official, only on blogs. I know the second is used to pass the client token to the server, vice versa also?

The header Token does not appear on MDN, nor on unofficial Wikipedia (en)

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

http token http-headers

  • First, I recommend reading: What is and what is JWT for?. In short: The client must make a request of the type post requesting the token(composed of cabelho.corpo.assinatura), the response to that request should be added a hearder Baerer with the Jwt token. You must have some mechanism in the back end to validate whether the token is valid in the next requets

  • 2

    If it’s in C#: ASP.NET Core 2.0: JWT API authentication (JSON Web Tokens)

  • @Marconi the doubt is not how JWT works or how to implement it, the doubt is what is the most recommended way to send it from server to client, ie, the creation and validation is already ready and working. None of the links talk about it, just how to implement and how to send from client to server (what I already know)

  • Mano follows a detailed tutorial on how to do , part 1 https://imasters.com.br/front-end/implementando-autheno-jwt-utilizando-react part 2 https://imasters.com.br/back-end/implementand-autheno-autheno-jwt-o-backend

  • Hello friend, I believe that what you are looking for is something related to refresh tokens and Sliding-Sessions (sessions that expire in a given inactivity), take a look at this article, he talks about.

1 answer

9

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

As for the header Token I don’t know you and I also didn’t find references to them, very likely it’s a custom header, I usually see this term associated with the token scheme as if it were a more generic scheme, other terms for the scheme are Bearer and Basic only that these two specify the token type.

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

Now, why is it better to have a feature that authenticates the cliete and returns a token than the API itself to deliver a token to the client when its token expires? Let’s look at two scenarios:

In the first scenario one CLIENT TO authenticates and receives a token X. This token X is captured by a client B that uses it to make requests. After 10 minutes the Espira token. When the Client A make a request to the server will receive a new token (the Token Y) and, likewise, when the Client B make a request you will also receive a new token for it (the Token Z). Soon, in this scenario, the Client B even without having done the authentication correctly (since he "stole" the token of the Client A) achieves a valid token for requests to the API provided by the API itself.

In the second scenario one CLIENT TO authenticates and receives a token X. This token X is captured by a client B that uses it to make requests. After 10 minutes the Espira token. When the Client A make a request to the server will return with an error message and request that the client authenticates again to receive a new token (the Token Y) and, likewise, the Client B will also receive a message requesting you to autentique novamenete. Soon, in this scenario, the Client B initially manages to request the API using the captured token of the Client A but when this token expires it will lose access to API having to capture a new token.

Final Considerations:

  • The 10-minute limit for a token is rightly 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 from authorized customers.
  • The client’s access token is almost always sent in the body of the reply to the authentication request. This may seem unsafe but if you are working on HTTPS this information will be encrypted.
  • 1

    The problem of one customer stealing another’s token can be solved by storing in the database which next valid token, this also prevents two users from using the same account at the same time. Also, if he managed to steal the token once, he could probably do it again. Also asking the user to re-use every 10 minutes is bad for UX. Also, for the API to send a new token only when needed without a user re-user it would need a socket, which would increase the complexity of the system unnecessarily, outside that if you have ...

  • 1

    A socket connection you don’t even need tokens for authentication. The 10 min limit is so that if the person stops using the system (inactivity), he or she is disconnected. Actually it wouldn’t even be 10 minutes, it’s a short time, it would be at least 30 minutes

Browser other questions tagged http token http-headers

You are not signed in. Login or sign up in order to post.