WebFlux oauth2Login returns 500 when bad client credentials

[jgrandja]

When WebFlux oauth2Login is configured with 1 ClientRegistration that has bad client credentials, a 500 response will occur during the processing of the Authorization Response when attempting to exchange the code for the access_token. The parameters from the authorization response are also viewable in the browser location bar.

We should ensure a redirect to the default login page to display the error message, for example, [invalid_client] Unauthorized.

[rwinch]

In my opinion this is a this is a configuration error that should result in a 500. Why should we do this?

[jgrandja]

See invalid_client

[rwinch]

@jgrandja I'm not sure I understand. All I see is what the authorization server should do. This code is discussing changes to the client.

[jgrandja]

@rwinch I agree that it's a configuration error but we should at least help the user by displaying the error message coming back from the Authorization Server so they have some indication on where to resolve the issue.

Here are the results when I tried the Servlet-based oauth2Login sample with an invalid client_secret configured:

Google

Okta

[rwinch]

Thanks for the response. This does seem like a reasonable improvement, but I don't see this as broken. I'd guess that URL includes the same error information in it so the user should be able to figure it out.

[jzheaux]

I think that there is value in bringing the reactive experience into parity with the servlet experience. It would be nice if both redirected to "/login?error" (servlet-based oauth2Login already does this).

To achieve this, though, there are some more basic features, as I see it. LoginPageGeneratedWebFilter does not yet support any way to pull an error message from the session or the request. Also, RedirectServerAuthenticationFailureHandler does not save any error message to the session or request.

@rwinch @jgrandja do these two features seem reasonable for Reactive applications? If so, I'll create tickets for those.

[rwinch]

It is tricky because we don't want to reveal too much information about the log in failure. In general, explaining too much information (i.e. the username does not exist, the password is invalid, etc) is not recommended.

If there is a failure in the systems, then I think the general error page should be used rather than our default log in page trying to handle it.