1

I have some questions about my implementation of bearer token security (JWT to be specific) in an asp.net core 2.0 project that I'm working on. The bearer token is used when the frontend web app talks to a separate Api (both are controlled by me and live on the same server).

First, let me summarize what I implemented and my reasoning:

Access Tokens are stored via a secure http-only cookie

I believe this limits the attack surface to just XSRF (correct me if I'm wrong). To prevent against XSRF I have implemented antiforgery/XSRF tokens.

Access Tokens have a version number

My Users table has a column for Token Version, and this number is included when issuing an access token for the user.

  • If the token versions don't match during authentication/authorization, the request is denied and a challenge is issued
  • There is logic that automatically updates the token version when applicable (i.e. An admin locks an account, the user changes their email or logs out, etc) - It can also be manually changed if needed, for example if it becomes known that a specific account was compromised or any other valid reason for revoking access
  • Side note: I've implemented a way to avoid constant database hits when active users require the version number check and can elaborate if needed but I don't think it directly applies to my security concerns in this question

No Refresh Tokens and long expiration for Access Tokens

I don't use refresh tokens at all, and my access tokens are set to expire after 7 days (unless "remember me" is unchecked, in which case the expiration is set to Session). Here is my justification:

  • The token version functionality solves the issue of needing to revoke an access token while its expiration is still valid
  • Even with very short access token expiration, a compromised account/session could simply use the longer lived refresh token to acquire a new valid access token, so I'm just cutting out the middle man (correct me if I'm wrong or naive)

So, here are my specific questions (and to clarify, I'm not asking for opinions on best practices and such but for objective answers about whether or not the implementation satisfies a reasonable level of security):

  1. Does using a http-only cookie limit the attack surface to just XSRF attacks? And can XSRF be "completely" prevented via Antiforgery/XSRF tokens?
  2. Is a token versioning system a valid way to ensure proper access revocation?
  3. Is it reasonable to forego refresh tokens and allow for longer access token expiration times when a token versioning system is in use (and tokens are protected via the http-only cookie and antiforgery tactics)?
  • "I believe this limits the attack surface to just XSRF" Seems like XSS is still an issue. – AndrolGenhald Jan 9 '18 at 15:30
  • How so, could you please elaborate? Is there something else I can do to mitigate XSS attacks? – debuggingmyhead Jan 10 '18 at 14:47

Your Answer

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

Browse other questions tagged or ask your own question.