2

I want to build a REST API but I have some holes when it comes to the security part. I would like to get my head around how to authenticate the calls to the API.

Therefore, this is my first draft for how the process should be:

  1. User account is created
  2. Token is automatically generated and stored in db, associated to that user
  3. User calls login endpoint
  4. Obtains their token as a response Token
  5. The token is stored in the client side as long as the session lasts
  6. The token is used to make the rest of the calls

I have to admit I am not fully convinced about the idea of returning the token when login is called but I need your advice about whether this is a good idea or not. If not, please, give me some advice to approach this situation.

  • So whats your idea then? – Sazzad Hissain Khan Mar 8 at 7:15
  • My idea is the draft with the number points I described. – NeoChiri Mar 8 at 11:16
  • I'm not familiar with security, but... wouldn't it be better to have dynamic token created after successful login (or after every authorised API call), rather than creating a static one right after account creation? If someone manages to get the static token, will she/he be able to access your APIs bypassing login step? – shiouming Mar 9 at 15:15
  • If using dynamic token, there's no need for clients to store it locally, so step #5 becomes unnecessary. – shiouming Mar 9 at 15:24
4

With the step 2. you are not creating a token, but just an alias for the user credentials.

The real purpose of a token is to get rid of credentials during the client session, since every time the user shows the secret proof of its identity, he/she is exposing the identity itself to attackers.

This means that tokens have to be generated "just in time", after login (so is fine to send them as a response of /login, if the communication is encrypted) , they have to be random (at least partially) and temporary, so that attackers able to steal them can make damages only in a limited time window. There are two options to manage token expiration

  1. force the user to log in again
  2. use the refresh token

Refresh token live longer than the access token and can be used only one time to authenticate the no-longer-authenticated user to make a request to a special /refresh endpoint. Calling the /refresh api, the client will obtain a new access token and a new refresh token. It's up to the client keep the refresh token in a secure storage as there are major risks in case of leak

| improve this answer | |
2

If you want to go the route you described I would recommend looking into this: https://winsmarts.com/access-tokens-and-refresh-tokens-and-id-tokens-5261bc26e8a2. Also look into OAUTH 2 and OIDC.

But I agree with the previous comment, it is best to use a vetted library than it is to make your own. Furthermore I must caution you with JWT. Those tokens are base64 encoded and only the signature is encrypted. So is the token was ever to be compromised the attacker could see the attributes in your token. Additionally if you do not use a strong pass key an attacker could decrypt your signature and the rest is history.

My advice is the season token should be randomly generated every time the use connects and after a certain period of time (15-60 mins). I don't know what language this is in but I'm going to provide some python references (guessing you might be using python). But even if you're not using python, this will still point you in the right direction (conceptually speaking) 1. https://oauthlib.readthedocs.io/en/latest/oauth2/tokens/bearer.html 2. https://docs.python.org/3/library/secrets.html 3. http://python-oauth2.readthedocs.io/en/latest/token_generator.html

| improve this answer | |
  • This seems a better improvement having a temporary token which is generated every time the user logins instead of making one when creating the account. But this raises a concern. How should the client deal with this? If the token expires, it should do login again? – NeoChiri Mar 8 at 11:15
  • Yes the user would have to log back in. The only time you'd have a "dormant" token or key is if you're dealing with an API gateway/service or a mobile application. But ideally you want just in time auth (as the winning comment suggested). – Mad Hatter Mar 9 at 13:27
1

The first rule of securing your system is not to write the security part yourself. You need to delegate the security of your system to other third-party libraries or even services.

However, regarding your draft, you must generate the token when your user logged in as opposed to when they first created the account. The token has to have a short lifespan. You can use cookies or JWT to verify the identity of users for each API call. Also, be aware that there are two things in securing your APIs: You have to authenticate your users and authorized their requests.

| improve this answer | |
  • Yeah, I didn't mean to write all the security part by myself. I wanted to delegate the token generation, user authentication and request authentication to third party libraries. But still the process of how to do it must be implemented by me. Regarding the token's life, how should the client deal with the expiration? I am not making any client side yet but I want to keep it in mind once I do. – NeoChiri Mar 8 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.