0

I have clients which are all browsers. All clients render just a single page application getting data from a Web API. The design of the API follows REST principles.

I use token-based authentication without OAuth because I have no third parties for my API and I want to feel how security can hurt my brain ;-)

The format of my token I issue is Json Web Token (JWT): It contains the userId, lifetime (exp date), issuer and signing key (alg: HS256 which is SHA-256 hash algo)

The token is valid 7 days. So the user has to reauthenticate every 7 days. (Maybe thats not yet the final solution in this field...)

This is my authentication flow:

1) I use basic authentication over SSL for my login endpoint

2) If the user`s sent username and password are valid I put a token into the response

3) This token is stored in the local/session storage on client side

4) Each further request to a ressource endpoint of the server API must include a valid token else the request gets a 401 and sees the login view again.

5) Before I do further investigation with the token like checking its expiration date I need to know wether the authenticity of the token is still valid or a legit user has modified it. This assumes that the token was signed with a key before which we call MAC (Message Authentication Code)

I validate the token with the same signing key the token was signed during token creation. I store the signing key which is a bunch of randomly generated numbers in the user sql table belonging to the userId. The userId I get from the token see above. Or better said I store the hash of the key (byte array) in the user sql table hashed with BCrypt.

Question:

  • Is there something wrong I do?

  • Should I store the full token in the database instead of the signing key only and whats the advantage?

Improve this question

1 Answer 1

Reset to default
2

On your first point, there are some potential downsides and points to using basic authentication over SSL that you might want to consider.

  • Where you're using basic auth, your token based solution might not really be needed as once a browser has sent the basic auth credentials in the first place they'll send them again with every request to that realm, so you could just check them again and not bother about the token :)
  • Basic auth sends the user credentials in encoded format over the link, anyone who can see the data in transit can get the creds. Now SSL will of course provide some protection but it still carries a bit of risk, in some scenarios. You might want to look at digest authentication if you persue this authentication scheme
  • By itself basic auth doesn't include some authentication protections which could leave your application open to attack. For example there's no account lockout, no password quality requirement, no logout functionality, no password change functionality and no protection against the one user having multiple simultaneous logins.
Improve this answer
2
  • 1) When the browser is closed the user still wants to be logged into the system. Therefore I need the token mechanism. 2) This is done one time only the other times I use token :) 3) I use my own login view (not the basic auth form) sending "basic email+password"-encoded in the auth header. Thus I also force the user to choose a strong pass stored in the DB as hash. Login out is just a matter of deleting the browsers website data (local storage) else user has to re-authenticate. NO Problem at this point. blog.auth0.com/2014/01/07/…
    – Elisa
    Commented Feb 10, 2014 at 7:59
  • Depending on the requirements, I can't see how basic authentication over TLS is any better than a login form and a session cookie. @RoryMcCune already laid out how it is worse. [Here's me reading a well written essay of a very recognisable aspect when I read the name. Oh :-) We've been colleagues in the past. ]
    – Pedro
    Commented May 1, 2020 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .