I have created multiple SPA applications in Okta. Each of these applications uses a JWT token to communicate with the Backend Java service. Now there is a requirement to set different session timeouts for each of these applications. So I created a rule for each application under Security > API > Authorization Server > Access Policy and set the appropriate access token lifetime. But this is still not working and logging the user out of the application even before the access token expires.
Hello,
Are you using one of our SDKs, and if so which version?
With the later SDKs a user will be considered logged in if they have both an access_token / id_token present in the token store and both are still valid (have not expired).
What could be happening is your access_token session expire might be set longer than 1 hour, but the id_token will be set to 1 hour and can’t be changed. Depending on your Orgs Sign On policy, a users Okta session lifetime could be set to less than the access or id token. So when the id or access token expires, the SDK tries to do an /authorize noprompt call. If the Okta session has already expired this will fail, and you will be logged out the of SPA app. To work around this a couple of solutions,
Set a longer Okta session lifetime in Sign On policy
The better option would be to use a refresh token if not already. Using a refresh token does not reply on the Okta session cookie for your domain. Anytime either the id_token or the access_token is about to expire the refresh token will renew it. More info can be found here and here.
Hopefully one of the above will address the problem.
We are actually using the local storage to store the access token for our applications. I think I will go for the second option you mentioned. Also, thinking to go with refresh token rotation for more security as our apps are SPA apps.
I have one question here. If we want session timeout when the user is inactive for 30 mins setting 30 mins expiry time for both access token and refresh token should ideally work right?
We are actually using the local storage to store the access token
Does this mean you are not using an Okta SDK like okta-auth-js? If you are using your own storage manager then you will need to take care of refreshing the tokens on your own and can have built in logic to expire it if the token is not used for a certain amount of time.
If you are using auth-js with a refresh token, the token manager will continue to update tokens in the background as they near expiration. There is no idle timeout setting. To accomplish something like that you could modify the tokenManager to reset a timer each time a token is accessed. If the timer ever hits a certain amount (30 minutes) that would mean the user is inactive and you could log them out.