OIDC logout error when the user is no longer logged in


#1

When redirecting a user through https://developer.okta.com/docs/api/resources/oidc#logout, if their Okta session has already be killed they’ll be shown a JSON error page that looks like:

{
    "errorCode": "E0000005",
    "errorSummary": "Invalid session",
    "errorLink": "E0000005",
    "errorId": "oae4uSVaLVbRTOoRB_EsrXMWw",
    "errorCauses": []
}

As obliquely mentioned in the error cases in the documentation. What I expected before testing was that if there wasn’t a session or a user who didn’t match the id_token was logged in, the browser would just be redirected back to the post logout redirect uri (assuming it was valid) without having killed the session.

What is this error for and as result of this happening, who is OIDC logout supposed to be used? This page is clearly unacceptable to ever show to an end user. We can’t avoid that by running this via a CORS request or in a hidden iframe since this page supports neither CORS calls or embedding unless we set our whole Okta org to be embeddable in an iframe. We don’t want this app to have full CORS access to Okta (or we’d just use https://developer.okta.com/docs/api/resources/sessions#close-session) so we can’t use https://developer.okta.com/docs/api/resources/sessions#get-current-session to check if the session still exists. Okta doesn’t support (http://openid.net/specs/openid-connect-session-1_0.html) so we can’t easily use OIDC to continuously track if the user is still logged in. I suppose that on logout we could redirect the user through authorize again with prompt=none to check if there’s still a session to kill before sending the user through logout but that seems like a big hassle.

Am I missing something?


#2

Hi-

It looks like you’ve identified a not-so-great behavior in our OIDC logout flow. You’re right that we wouldn’t want to send a user to this error state. I’ve logged a bug internally for us to re-direct to the post logout uri even when a session is expired. While I can’t provide an ETA for this to change, we are tracking this internally now and will fix the behavior in the future.