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

    Mapping Fusion Auth's user ID with our internal user ID

    Scheduled Pinned Locked Moved
    Q&A
    data mapping ids user ids
    2
    3
    1.8k
    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.
    • A
      ashok
      last edited by dan

      Hi,
      We have an internal table for storing user information which much more columns. How does one go about mapping them? I can think of adding a new column in our table something like fusion_auth_id to save FA's id or use a claim field in FA to save our ID. Is there a better way? Also, our registration is self served and we don't plan to use registration API. Given that, where should we "map" the ID? Using a webhook?

      Thank you!

      1 Reply Last reply Reply Quote 0
      • danD
        dan
        last edited by

        How does one go about mapping them?

        How are you planning to use this extra data? That would inform any recommendation, as the two options you mentioned are both fine, but with different tradeoffs. You could also store your internal id in the user.data field.

        Given that, where should we "map" the ID?

        If the registration is self served (that is, you're using FA's registration pages, possibly themed) then a webhook makes sense--the alternative is polling the user API.

        You probably want the user.create or user.registration.create events, depending on if users are registering with only one FA application or with more than one: https://fusionauth.io/docs/v1/tech/events-webhooks/events

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

        1 Reply Last reply Reply Quote 0
        • A
          ashok
          last edited by

          Thanks for the reply @dan.
          We ended up storing sub ID on our side. We thought that might gives us more flexibility down the road (not sure about this but if it doesn't work then we'll have an extra column in the db; a small price to pay IMHO).

          "Where to map the ID?" was a bit headache for us as we didn't want to miss it or make an extra call by polling ourselves. Since we are using .NET Core, we ended up hooking into OnUserInformationReceived event, one of many from OpenIdConnectEvents. Hopefully, I'm not doing something really stupid.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post