Support the prompt parameter

[robotdan]

Support the prompt parameters

Problem

If you want to use the prompt parameter, you can't. It is sad.

Solution

Support the prompt parameter.

• none (support for silent authentication)
• login
• consent
• select_account

The login prompt would likely solve the issue requested via https://github.com/FusionAuth/fusionauth-issues/issues/1999.

Alternatives/workarounds

NA

Additional context

OIDC

• https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

Silent authentication

An example 3rd party library using this parameter to do a silent "renew"

• https://github.com/authts/oidc-client-ts/blob/30a40e177a0b9c14a6bd4d98a22042c5ca8e8f97/src/UserManager.ts#LL255C24-L255C30

Auth0 doc for this feature:

• https://auth0.com/docs/authenticate/login/configure-silent-authentication

Related

• https://github.com/FusionAuth/fusionauth-issues/issues/521
• https://github.com/FusionAuth/fusionauth-issues/issues/1999

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.

[smboykin]

It would be wonderful if this can be implemented, this would make 3rd-party integration with a difficult customer - well - less difficult :)

[jdegger]

Is there a roadmap on this? This is basically making it impossible to do a good implementation for our users

[mooreds]

Hiya @jdegger , this is not currently on the near term roadmap. Please upvote it (if you haven't already, I don't know how to see individual upvotes).

Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

Thanks!

[ohEmily]

Just to chime in, my company is also really interested in this. It's a bad look for us right now that our new auth provider doesn't support this (highly visible) white labeling feature for auth applications.

[robotdan]

For all on this thread, are you mostly looking for prompt=none, or do you have use cases for other values?

For some context, here is how I am thinking about each of these prompt values.

---

none This would be valuable as a silent check to see if the user has an SSO session. I can appreciate the value here, and seems like something we should support.

login The use case here I think is to force the user to authenticate again even if an SSO session exists. The scenario I have seen discussed is for this to be used when the user is doing something that may be considered sensitive and you want to force the user to auth again.

The problem is that this parameter doesn't provide any security - the user could simply remove this parameter from the request to bypass this requirement. So if you were to want this feature for this use case, it doesn't seem like it actually offers you any security. It would only be a hope that the user does not modify the URL and then re-use their existing SSO session.

Feel free to comment if you have an opinion on this one, or if there is another use case that you think this solves that would not require any confidence that the user actually re-authenticated.

The way I would think about this - is if you really need the user to re-authenticate, you should perform an in-app step up, or delete the user's SSO session and then redirect them to login to ensure they must login.

One option would be if, if the returned access_token or id_token contained a claim indicating which prompts were requested (and honored) then the implementor could at least prove that they both asked for login and it was completed. But I think this is mostly already possible because today if we honor an existing SSO session, the authenticationType in the access_token will be PING instead of PASSWORD or some other type.

consent Similar to login, this could simply be removed by the user and then they would not be prompted. We have implemented scope consent through the use of a "3rd party" application setting which forces a prompt based upon configuration instead of a mutable parameter on the URL.

Does anyone have a use case that would require consent, and you wouldn't otherwise be able to use a 3rd party application config, and would want to enable or disable consent on a per request basis? Knowing that the user could intercept this URL and remove or modify this parameter?

select_account

This seems interesting and would allow you to select from multiple active SSO sessions for users in the same FusionAuth tenant. Currently this is not possible. We do support multi-tenant SSO, but if you have more than one user in a tenant, you can only have one active SSO at a time.

Is this specific option interesting to anyone?

---

Feel free to leave comments for any other specific use cases I'm missing here. Thanks for your interest!

[jdegger]

@robotdan For us, we are looking for the prompt=login variant, the use case is very different from what you are describing. This is important because the solution you are providing is not working as expected.

We are relying on solutions like react-native-app-auth to provide us with the login screen in our app. On iOS we have the option to choose for a private session which makes it possible for us to pick up on the correct user but on Android the login credentials of any existing user are cached and passed through. This results in the wrong user being logged in, which we can not prevent.

The three solutions being provided in the community are (https://github.com/FormidableLabs/react-native-app-auth/issues/723)

• Logout beforehand: this is not possible because the session is being setup outside of our app and just passed through
• Use a private tab: works wonderfully on iOS. No working solution on Android as of now.
• Provide prompt=login to force the login: not supported by FusionAuth.

The use case we are struggling with is as follows:

1. User A logs in with a SSO provider, all good, no problems
2. User A logs out from our app. Note that this not invalidate the SSO session at this point.
3. User B tries to login. He does so by providing his e-mailadres in our app, our app detects through FusionAuth that this is a domain which has been linked to an external SAML provider and thus we need to provide the login screen to the user. However, FusionAuth picks up on the existing SSO session and logs this user in. Even though we have provided a login_hint with a different e-mail address.
4. The login was now successful, but you are now logged in with a different user session than expected.

The prompt=login would resolve the issue where we can make sure the correct user is signed in, the one we asked for.

[jdegger]

Additionally, this behavior was also described here: https://github.com/FusionAuth/fusionauth-issues/issues/1999

This is linked as a related issue in the original ticket but I do not see this back in your understanding of adding and supporting prompt=login

[alex-fusionauth]

This would help us add Authentication to other providers like convex. The way that convex currently handles this is to make an additional call to get the accesstoken passing it back to convex.

Example using Auth0 https://github.com/get-convex/convex-js/blob/47343e1c7531233a1782b03223d3f31e90c75623/src/react-auth0/ConvexProviderWithAuth0.tsx#L45

Open PR to add FusionAuth: https://github.com/get-convex/convex-js/pull/13