• Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login
FusionAuth
  • Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login

Force Login with and without idp_hint

Scheduled Pinned Locked Moved
General Discussion
2
2
564
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G
    ghstahl
    last edited by 30 Jan 2024, 23:51

    I have setup a few IDPs for my application. In in OIDC client I pass an idp_hint which works when there are no cookies dropped. A cold login.
    How do I force another relogin by passing a different idp_hint?
    How do I force a relogin?

    The use case is.

    • User has logged in using their email/password

    • I want to challenge them again against a well known IDP, hence a forced login by passing the idp_hint. This doesn't work, it just returns that original id_token.

    What I want: I need an id_token that contains the users information and the current IDP that was used for the login. (edited)

    D 1 Reply Last reply 5 Feb 2024, 19:51 Reply Quote 0
    • D
      dan @ghstahl
      last edited by 5 Feb 2024, 19:51

      @ghstahl I think we had a similar conversation on Slack 🙂

      For future readers, if you want to be able to distinguish how a user logs in (which idp they use), this might be helpful:

      If I were you, I'd look at two things:

      • the user login success event: https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success which has the identityProviderId It is provided as an event, so I don't know if it'll work for you, but it will tell you on every login event which idp was used. You could possibly store that off someplace and build a system to exchange an id token for the idp used. I'd have to think more about how that works, but it might be possible.
      • setting up in your own app a 'sign me in' button and not using an idp hint. You'd instead build the authorization URL for each idp and build a link for entry into each navigation area. https://fusionauth.io/docs/apis/identity-providers/openid-connect#complete-an-openid-connect-login You'd let the user login and then come back. The redirect URL could be different and that would be the distinguishing feature.
        If a user started at /googlestart, clicked the 'sign me in' button, and arrived back at /googleendpage and had a valid token, the user went through the google process.
        If a user started at /secretidp1start, clicked the 'sign me in' button and ended up back at the /secretidp1endpage with a valid token, then the user went through the secret idp 1 process.

      --
      FusionAuth - Auth for devs, built by devs.
      https://fusionauth.io

      1 Reply Last reply Reply Quote 0
      2 out of 2
      • First post
        2/2
        Last post