• Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login
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 28 May 2020, 17:36

    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
    • D
      dan
      last edited by 28 May 2020, 21:11

      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 28 May 2020, 22:35

        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
        1 out of 3
        • First post
          1/3
          Last post