A Hybrid Approach to Continuous Application Authorization

Applications need to maintain logged-in “sessions” for all users that use their app. Once a user logs in, they can continue to access parts of the application without having to log in (i.e., authenticate) again and again for each subsequent request made to the server. There are two main ways to do this: one is JSON Web Tokens (JWTs), and the other is session tokens. Both have pros and cons. Now, there’s a hybrid approach that takes advantage of the best of both. 

JWTs and Session Tokens: Pros and Cons

With JWTs, the user data is stored client-side within the token itself. This makes JWTs a popular session management solution among developers looking to reduce their server load and improve latency. One downside is that session cancellation can be more difficult because the validation happens client-side rather than server-side. Due to the client-side validation, this can cause greater security concerns because you can’t easily revoke the underlying session if there’s a threat.

Despite some of its security concerns, you might want to use JWTs if your application would benefit from the performance improvements of validating user sessions without an external network request or if you are using sessions to authorize actions outside your app and that authorization works via JWT.

On the other hand, session tokens are a session management solution that stores the token on the server side, along with user data. Session tokens are verified against the server’s database with every user request. This results in higher latency than JWTs. However, when control over session revocation (security) is critical, this solution can be beneficial because it guarantees instant session revocation when needed. 

Session tokens are ideal if your security needs require that your app must never accidentally use a revoked session (i.e., even the small five-minute grace period of most default JWTs is not acceptable to your app's security). Other circumstances that warrant session tokens are when access to user-side storage is limited and can only store small values or when you don't want to expose the session data (authentication factors) or metadata (timestamps) in user storage.

New Hybrid Approach

Developers typically must decide which session management solution is best to implement and make the tradeoff between security and latency — but that doesn’t have to be the case. JWTs offer performance benefits; session cookies offer more security. Now there is a blended option that can be customized for any organization’s particular needs.

An extremely security-conscious organization, like a bank or government agency, might want to solely use session cookies in order to ensure that every single call is authorized at that exact moment. But other applications might want the performance improvements of being able to do client-side JWT validation but still prefer to have some sensitive actions that require a source of truth to check in with before granting access. Applications without any sensitive info might value the performance benefits of JWTs and almost never want to ask their users to re-authenticate but still want to be able to honor explicit logout requests.

With the new hybrid approach to session management, you can configure the duration of a user’s session and determine how long the overall session will remain active before prompting the user to re-authenticate (e.g., 30 days). After doing so, you can create both a session_token and JWT for this session. By making the session_token a static value that is good for the lifetime of the session, you can then ensure that the JWT that is associated with the underlying session has its own shorter-lived expiry of five minutes. Expired JWTs can be refreshed in the background without rocking the user to log out if the underlying session_token is still valid (in this format, the session_token operates as a refresh token). If the user logs out, this revocation of access will take place within a maximum of five minutes. If you have a particularly sensitive route, you can set an even more restrictive max_token_age which can be used to request a new JWT, lowering the threshold for potential staleness even further.

This solution allows for a nice balance between performance and security. Getting started with session cookies is easy and secure. But as your app scales, you may start to notice the latency of the required API call. JWTs can help you reduce the number of calls you need for non-sensitive routes. If the API call only needs to happen every five minutes or before granting access to particularly sensitive actions, this greatly reduces the performance overhead while also protecting you and your end users from the risk of authorizing actions based on stale information.

The Right Balance Between Security and Responsiveness

This hybrid solution allows for a balance between performance and security. While there may never be a clear consensus on which method is superior, the good news is that there is now a blended approach with the ability to configure the perfect combination of latency and security for any particular use case.