1

I have built a REST API, where users login, with extra permissions in some cases (or restricted to certain areas of the site; or even admin privileges).

What I've built:

  • JWT authorization (added to each request from ES6 [Aurelia] client)
  • Backend Python [Flask] checks JWT for signature, invalid errors, expiration every time. All checks occur before each request... In the headers ("Authorization Bearer") to backend.
  • Redis cache, timed set values, for storing sessions to reduce constant signature checks on each request (overriding the above a bit).
  • Cookies restricted to domain by default is the main delivery of the initial authentication. Cookie brings JWT produced in Python.
  • HTTPS for transmissions
  • All my requests are application/json, aside from maybe 2 forms, and a number of GET requests which are just retrieving data
  • I don't have anything where user info is being printed out based on the cookie or cache value.
  • JWT has the domain set. Issued token must match IPs forwarded.

I don't believe (I could be wrong) I need to create an XSRF-token claim inside the JWT separately. Both the JWT & Redis cache items have expiration short enough (30 minutes). Not a single thing can be operated without logging in except for the redirect paths that take you to the login form. All major administrative functions require "confirmation" and "relogin" sometimes.

My goal is to knock out multiple birds with one stone through the JWT.

What improvements can I make to this? Am I vulnerable to certain types of attacks?

Improve this question

1 Answer 1

Reset to default
2

The authorization header will protect against the csrf. Your responses in json will be XSS protection mechanism. With the information you provided on the JWT claims, seems the token do not have claims to handle token revocation mechanism. This is to handle the corner case of stolen token. It is advisable to have specific token revocation mechanism as per my view.

Of course, this is post attack mitigation strategy and this will not prevent any attacks per say.

  • Sanjay
Improve this answer
2
  • You mean like the "nbf" & "iat" claim? The not-before to revoke old tokens ? I think those should be implemented, but i'm hoping I don't need "at_hash" or "aud" or "jti".
    – Dexter
    Mar 22, 2019 at 21:02
  • 1
    You can have your customized claims as a means for revocation. Standard claims are not mandate. Claims like nbf will not address the revocation. nbf validation will restrict the use of token if used before nbf value. If you think of any processing / validation which is token specific, then you need jti which is uniq ID for token. You can make the validation more robust based on your security requirement. Typically, the case where API are exposed to public, there are certain cases which are to be considered. One is the stolen token, other is the case of rate limiting.
    – Sanjay Phanshikar
    Mar 23, 2019 at 9:18

You must log in to answer this question.

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