3

I'm trying to secure a REST API that I'm using as a backend for a single-page application. The API provides access to read/create/modify/delete protected resources, based on a set of permissions managed by an administrator. What I'm thinking is the following:

  • All connections must be over HTTPS; plain HTTP requests will be redirected to HTTPS.
  • Users have a username and password, which they create.
  • A client submits a username/password to a /login route; if it's a valid password for that user, the server will return a short-lived access token and a long-lived refresh token.
    • The access token will be a signed JWT that identifies the user and has an expiration time.
    • The refresh token will be a GUID corresponding to a row in a database table; this row will store the user ID
  • When accessing protected routes (everything but /login), an access token will be required. The server will verify the signature, and if valid, will check the expiration time. If the token is not expired, the user ID will be made available to server-side code for authorization logic.
  • If the access token is expired, the client will automatically submit the refresh token to a /refresh endpoint for requesting a new access token. The server will check the database; if a corresponding row still exists, a new access token will be returned to the client.

Does this scheme sound secure?

  • I apologize for not including anything about a threat model; I'm not sure what information to provide on that front. – DylanSp Oct 25 at 13:58
  • 2
    Since I misunderstood (and thought that the refresh token was the GUID for the user table), I went ahead and deleted my answer. As long as your refresh token is revokable (which it is), then you're pretty much implementing a standard JWT authentication flow, and it sounds very reasonable. The devil is in the details of course, but from what you've described here I personally think this sounds fine. – Conor Mancone Oct 25 at 14:31
  • @ConorMancone Thanks for the vote of confidence! "Pretty much...standard" is what I'm aiming for; I don't want to try creating something too novel. – DylanSp Oct 25 at 14:39
1

Okay! Caveat emptor, first off: I’m a rando on the internet, don’t make decisions off this, YMMV, etc.

With that out of the way this seems pretty much fine to me. Nothing seems out of the ordinary here. The main thing I’d check is securing the secondary endpoints, like /refresh. Make sure that one can’t be fiddled with, for instance. And make sure you test all of this thoroughly in your test suite.

  • Thanks! Anything particular to check/test w.r.t. the authentication-related endpoints? – DylanSp Oct 26 at 18:55
  • Yes definitely! Make sure you can only do the things you’re supposed to be able to do, basically. Check that you can’t delete resources, that you can’t bypass authentication, check for providing incorrect or weird values, etc. – securityOrange Oct 26 at 19: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.