There’s a bug where users try to visit an authentication-required page with expired access and refresh tokens, which redirects them to the logout page. The logout page revokes those tokens via oktaAuth.signOut() (see below), but in the System Logs we see two failures due to invalid_token since the tokens are expired. The very next log is a failed sign in attempt to the Okta dashboard page, which is perplexing how they got there. Somehow users are getting redirected to the Okta dashboard sign on page, instead of our app. However, we have not been able to replicate this issue ourselves: even trying waiting for the tokens to expire, revoking them through Postman, and manually editing the browser cookies. In each case we call signOut and see a flash where it visits the Okta hosted page to revoke the tokens presumably and sign the user out, and then we are redirected back to our page immediately. In the logs we see the revoke failures due to invalid_token twice and then a log for “User log out from Okta SUCCESS”. We cannot pinpoint how they are getting redirected to the Okta dashboard sign on without hitting the logout path. Any ideas?
EDIT: we are using okta-auth-js version 6.7.3. The config we are passing to oktaAuth.signOut({
postLogoutRedirectUri: window.location.origin + ‘/login-ui/logout/’,
clearTokensBeforeRedirect: true,
})
I found this documentation saying that if postLogoutRedirectUri is not provided to the /logout call it should redirect to the Okta Sign In page, which is my best guess at what’s happening. However, the React documentation below it says that if postLogoutRedirectUri is not provided to OktaAuth.signOut, it defaults to window.location.origin, which is the behavior I’ve been seeing when testing locally… I’m not sure what is happening still for our users to have the /logout call send them to the Okta Sign In page. What I’ll try on Monday is making the postLogoutRedirectUri something that isn’t specified in the app integration settings. I was trying this function locally with unauthenticated users that didn’t have an Okta session, so the call would always 404 on the sessions/me call and immediately redirect to whatever postLogoutRedirectUri was specified or the window.location.origin if not. Perhaps it only errors due to invalid logout redirect uri if there is a session and then it might send to the Okta sign in page. Still, I’m not sure how the users are getting an invalid postLogoutRedirectUri, but we are dynamically building it as window.location.origin + “/login-ui/logout”, so perhaps it’s building the wrong url somehow.
It turns out this issue was caused by users arriving on our Logout page with invalid public keys.
We have automatic key rotation enabled for our authorization server and users who had not logged in since then but still had their tokens and old public keys in the browser were sent to the Logout page which calls the okta-auth-js signOut() function which includes a call to the Okta API /logout endpoint. Per Okta support: “One of the first things our logout endpoint does is verify the id_token which immediately fails [due to the old public key] and a 400 is returned.” The user is then redirected to a 400 Bad Request custom error page. The mitigating solution was to modify that custom error page to immediately redirect to our team’s Logout page if anyone lands on it. See this documentation for customizing the Okta-hosted error page. Here’s an example code snippet of what you can add in a script tag on the index.html for that page:
<script type="text/javascript">
const params = new URLSearchParams(location.search)
let plru = params.get('post_logout_redirect_uri') || "https://www.my-fallback-url.com";
location.assign(plru);
</script>
The first signOut call revoked and cleared the tokens from the okta-auth-js tokenManager so they shouldn’t land in this flow a second time and all is well.