On silent authorization challenge return, referrer policy defaults to `no-referrer`

[terflespie]

Which version of Duende IdentityServer are you using? 6.3.7

Which version of .NET are you using? dotnet core 6.0

Describe the bug On silent authorization challenge return from identity server, when response type is set to form_post, referrer policy in headers is set to no-referrer which removes referrer which is used for website analytics.

A clear and concise description of what the bug is. In our implementation of Identity Server, our client website performs a silent authorization challenge on each page request. In the OpenIdConnectAuthenticationOptions, we've recently updated our ResponseMode from query to form_post. Our analytics team reported that they were no longer able to report on organic search referrals. Investigating further, we found that this change caused the Referrer Policy in the authorization return to change from strict-origin-when-cross-origin to no-referrer which removes the value from document.referrer.

To Reproduce

Steps to reproduce the behavior. On client application, perform Request.GetOwinContext().Authentication.Challenge with Response Type = code, Reponse Mode = form_post. Notice in browser developer tools on authorization return to client, referrer policy defaults to no-referrer.

Expected behavior

A clear and concise description of what you expected to happen. When updating ResponseMode from query to form_post, Referrer Policy acts similar on silent authorization challenge return.

Log output/exception with stacktrace

Did not see related log/output related to bug.

Additional context

[RolandGuijt]

To avoid leaking sensitive information the OAuth specification specifies that no referrer should be included in the response.

Alternatively the referrer could be put in the authentication properties (AuthenticationProperties object) so it becomes part of the state of the flow which is protected. In addition: is there a specific reason you are doing the challenge with every request? Asking because the recommended way is to do it when the access token expires in an iframe with the prompt option set to none.

[terflespie]

"Alternatively the referrer could be put in the authentication properties (AuthenticationProperties object)" Currently investigating AuthenticationProperties

" is there a specific reason you are doing the challenge with every request?" In the scenario that a user signs out of oauth directly or on another client we need to unauthenticate the user from the current session on next page request.

[RolandGuijt]

Instead of challenging with every request we recommend front channel logout notifications if possible for SPAs without a backend. To avoid problems with browsers and iFrames when the SPA uses a backend (BFF), back channel logout notifications are the way to go.

[terflespie]

@RolandGuijt Appreciate you pointing me in the right direction, I noticed in the MvcBackChannelLogout example that if the user authenticates on IdentityServer and in a new tab visits a client non-secure page that they are not authenticated. How can we still achieve the silent login using back-channel notifications?

[RolandGuijt]

Please create a separate issue for this as this is deviating from the original question. I'm assuming the original issue was addressed, so I'm closing this one. If my assumption is wrong, feel free to reopen.