The handling of a consent cancellation from an Identity Provider should be configurable in FusionAuth

[akshay-unibuddy]

Consent cancellation from an Identity Provider should not go to FA Login Page

Problem

We are currently using fusionauth to to send our user directly to the Identity Provider login page by using an IdP hint. When the user logs in and accepts the consent it goes back to the redirect page we provided with the auth code from fusionauth.
But when the user clicks on cancel at consent screen, instead of going back to the redirect page we gave, it goes to the fusionauth login page which we don't want to happen.

Solution

A configuration option that enables us to either disable the login screen or bypassing it entirely by sending any messages to redirect uri given

Additional context

This is the page we are trying to avoid

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[mooreds]

@akshay-unibuddy just so I understand, this is what you see happening:

• user sent directly to idp with a redirect_uri of page1
• user denies consent
• user sent to the FusionAuth login page with error message (the one you screenshotted)

And this is what you want to see:

• user sent directly to idp with a redirect_uri of page1
• user denies consent
• user sent to page1 (without the authorization code)

It does seem like the second scenario is per the RFC 6749 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format...

Also, what version of FusionAuth are you running?

[akshay-unibuddy]

@mooreds Yes you have described the issue perfectly.
And the FusionAuth version we are running is 1.30.1

[mooreds]

Thanks! Would it be possible for you to check if the same issue exists in 1.36.1, the latest release?

[akshay-unibuddy]

We are running the cloud version of FusionAuth and I don't have enough permissions to bump up the version and the one's who could do this are on leave. So will have to wait for at-least a day or two to test this out.

But if you don't mind me asking, was it added in some of the recent releases? If so is it configurable from the dashboard?

[mooreds]

@akshay-unibuddy

I don't think it was added, but was hoping it was easy enough for you to stand up a docker instance and test this out (since I don't have an IdP app set up with consents currently configured). Thinking back over the release notes, I don't think so.

If it isn't easy for you to do, no worries, just thought I'd ask.

[voidmain]

In this situation, FusionAuth is actually the Client AND the Resource Owner. We are a Client to the third part IdP that you sent the user to using the idp_hint. AND we are the Resource Owner to your application.

When the user denies the consent with the third party IdP, that IdP is required by the specification to send FusionAuth an error response. However, the specification doesn't define how the Client should handle this response. As the Client, FusionAuth can handle this error however it wants and still be in compliance with the specification.

One possible option is to mirror the Resource Owner and also redirect with an error. The other option is to present the user with the option to log in using FusionAuth. We selected the second option because it was our thought that people would prefer to allow the user to log in using FusionAuth than fail the login altogether.

Based on that, this is really a feature request and not a bug. FusionAuth could add a configuration parameter to an IdP that allows you to determine how errors are handled. This option could be something like:

errorBehavior

And it could have options like:

• passThroughError
• returnToLogin
• displayErrorPage
• restartIdPWorkflow

I'll update this issue to be a feature request and rework the title to provide more context.

In the meantime, the workaround for your use case is to update your theme to see if there is an IdP error and redirect the user back to your application using a meta-refresh or JavaScript. It's not an ideal solution because we don't have an easy way to check for IdP errors, but something like this might work:

[#assign idpError=false/]
[#if errorMessages?size > 0]
  [#list errorMessages as m]
    [#if m?contains("Invalid request was made to Authorize endpoint")]
      [#assign idpError=true/]
      [#break/]
    [/#if]
  [/#list]
[/#if]