Redirect to access denied page

We too have seen this issue and I've found a way to consistently reproduce it.

1. Load the Drupal site in a new window and start the login process
2. Start the "Forgot password" flow to get emailed a link to reset your password
3. In a new private window, use the forgot password link from the email and complete the forgot password flow. Doing so should redirect you back to Drupal, but you'll end up with with a 403 Forbidden response.

From what I can tell, the above is happening because the "state" token that was sent back from the auth provider cannot be found (see line 229 of OpenIDConnectRedirectController.php). This appears to be because the state token is stored in session, tied to a cookie that does not exist in the new private window.

It's quite likely that this is behaving as intended since the state token that gets passed to the auth provider and then back to Drupal is used for anti-forgery purposes. If the forgot password flow is started and completed in the same browser window (or if a different window, ensure cookies are not cleared) then it completes just fine. However, confirmation of this would be appreciated.

We're having the same issue here (with version 8.1.4 of the module). What is weird is that when on the redirect page showing Access Denied, if you go to the address in the address bar, it completes the authentication.

From the reproduction steps that @joelfp I would consider this working as designed. Browsing between a browser session and incognito should never work because of the requirement of the session.

- One thing to check is that a member has the `openid connect set own password` if you want to reset a password.
- What is the IDP that you are using?

I think we need more information and solid reproduction steps to consider if this is a bug or not.