and in the network tab I see two revoke requests followed by a logout request:
POST …/oauth2/default/v1/revoke
POST …/oauth2/default/v1/revoke
GET …/oauth2/default/v1/logout?id_token_hint=eyJr…
These all return 200 OK.
But when I then redirect to login:
GET /oauth2/default/v1/authorize?client_id=0oa18sjj5xt6…&code_challenge=0cRjeimk…&code_challenge_method=S256&nonce=I8Cok…&redirect_uri=…%2Flogin%2Fcallback&response_type=code&state=86I27i4P…&scope=openid%20profile%20email%20offline_access
This succeeds!!
Shouldn’t this fail? It means it’s impossible to logout. Shouldn’t revoking and login out prevent this?
Yes the 3rd call should clear the Okta session cookie idx / sid depending. In the network tab in the browser dev console, for the …/logout call does the http response headers include a set-cookie for the sid/idx cookie to expire them?
If you do see the cookie(s) removed from the browser the next thing to verify is,
if your Okta Org uses a custom domain URL make sure you don’t have sessions for both your custom domain URL and the Okta domain URL. If you did and you logged out of the Okta domain URL but the /authorize call went to the custom domain URL that session would still exist.
if your user uses an external IdP registered in your Okta Org, logging out of Okta does not logout of the external IdP session. So an /authorize call might immediately redirect to the IdP where the session still exists, the user would be SSO into the application and get a new Okta session.