Okta OAuth2/ OIDC Token Expiry
When configuring your authorization server and access policies, it is recommended to align your token expiry with the intended usage of the service or application. While there is no blanket solution, here are some guidelines to assist you with making that decision.
*This is meant as a starting guide, the application usage should also drive your decision for a longer Access Token expiry and shorter Refresh Token expiry.
Token Validation
Now that you have an idea on how long to configure your token expiry, it is time to look at validation. There are two types of token validation. A Local validation occurs within the application whereas an Authorization Server validation requires checking with the token issuer. Local validation should be completed for every request and it is recommended that Authorization Server validation be completed for high risk transactions and/or every 1 to 4 hours (depending on request frequency and token utilization, this timeframe should be adjusted). If a possible exposure or breach of the Access or Refresh tokens occurs, it is recommended that immediate Authorization Server validation be temporarily enabled for every request.
Local - A local validation uses a JWT (JSON Web Token) validation library to check the token signature and also look at expiry and claims within the token (example: appropriate "scope" for the requested operation). Although a token may not have expired, it may have been revoked. In this case, the only way to be sure is to preform the next check which is with the Authorization Server.
Authorization Server - The token may also be validated with the issuing Authorization Server. This goes one step beyond local validation where a revocation check is also completed. This method also incurs additional network request overhead.
Application Sessions and Expiration
It is recommended that application session expiry timeouts take into account the balance between security and usability. This means that a user must be able to comfortably complete their tasks without being unnecessarily asked to re-authenticate. Every application that requires authentication should implement idle and absolute timeouts, and present a clear, easily accessible logout button or action. The idle and absolute timeout values should be set based upon each application intended usage and data criticality.
Idle Timeouts
The following table should assist your application development team to determine the best settings for idle timeouts.
Absolute Timeouts
Application absolute timeouts should be configured depending on the application usage. An application intended to be used by an employee during their day to day operations could be 4 to 8 hours. We have found that most critical applications (such as with the Financial Industry) implement an absolute timeout between 10-15 minutes.
Expiry Actions
When a session expires, it is important that the application expire the session from both the client and server side. The most important action from a security perspective should be server side expiration.
Further Reading
Summary
While no recommendation can provide blanket solutions for configuring your environment and applications, it is important to develop appropriate requirements that best suit your business. For example, Financial Institutions should have a stricter secure posture when it comes to session and token handling.
For a more personalized conversation on this topic, book a meeting with one of our Financial Institution Identity and Access Management Experts.
Comments