Handle Web application authentication tokens

Question

I am new to the token concept of Authorization.

I am developing angular app which calls the Web API built with asp.net core. I am currently using JWT(JSON web Token) to authorize the users. These tokens are issued after login and sent in authorization headers on every request. The tokens last for 30 minutes. Now the problem is, unlike cookies which can have sliding expiration, I have no idea how to implement sliding expiration. I am trying to implement refresh tokens, but I'm not sure when to issue a refresh token.

Should the refresh token be issued before every request? If so, how to invalidate them?

Should the refresh token be issued before the 30 mins expiration time, and the user can be authorized?

Should there be a scheduler to check for expiration of token before every 30 mins?

Answer 1

There's a few different alternatives and as always the most appropriate will depend on a lot of things.

In general terms, if both the Angular application and Web API are under your control (same domain or sub-domain) I would not exclude the possibility of just using cookies. It may make things simpler, although you now have the downside of having to deal with the possibility of CSRF.

Another option, maintaining the use of tokens is to automatically renew them much in the same way as a session cookie. For example, returning a response HTTP header containing the refreshed token. You could do this only after the half-life of the token has passed in order to reduce the overhead on the wire. This has the downside that a leaked token, can be automatically renewed forever by the attacker.

In terms of refresh tokens (see security consideration section), if you end up storing them in the same place as an access token you would be in an identical situation to the previous scenario in case of a leak so may not be of much help.

Still assuming the same domain possibility, you could try a mixed approach, login returns access token and sets a sliding expiration cookie that allows to call into a specific endpoint to get a refreshed access token. Has the benefit that you don't need to worry about CSRF because access is granted by access token and reduces the likelihood of leaking a long lived credential (the reasoning being, that the cookie would be HTTP only, secure and scoped to the path of that specific endpoint). This would ensure that any XSS vulnerability on your application would only leak a short-lived access token and CSRF would not be an issue because you could leverage same-origin policy to not disclose the access token returned by that endpoint.

On a completely different note, you can go full OpenID Connect/OAuth 2.0 either by building your own identity provider/authorization server or by relying on a third-party solution like Auth0 (disclosure: I currently work at Auth0). You could then maybe go with an implicit grant flow that could provide with new access tokes automatically as long as the user kept a session active in the identity provider and did not revoke access to this application.

Bottom line is that authentication and authorization are not linear topics...