Forgive the noob question, I’m trying to properly frame the appropriate use of OKTA inside my projects.
Say, your users enter a lot of profile data into your app that results in a large JSON object (many fields, many objects, many arrays of data that is not related to authentication or role-based authorization. My current thinking suggests it makes sense to keep that data inside my own database and not put it in the users’ OKTA profile.
So, I would, for example, associate the sub returned from OKTA with the respective internal user’s profile in my database.
So, my users would authenticate via OKTA, and after that, I pull any of their additional information out of my own database.
Is this good practice? Or is it better practice to consolidate everything regarding user profiles into OKTA?
I’d say, if all of that information is relevant only for a particular application, then keep it locally. But if you have multiple applications which need a shared piece of information, it’d be beneficial to have it in Okta, so that you “change it once in one place”. An example of Last name maybe a good case. If a user changes their last name, you would need to change it in every system keeping its data locally vs having it in the cloud/shared storage. I hope, it helps
Hi @coderite - I have a very similar question to you and stumbled upon this. It appears based off the response you received, it’s best to keep this user profile separate and internal in your own database. A few questions:
• Did you end up implementing it this way (user profile in your own database and OKTA for authn/authz) - if so, how did this end up working out for you?
• Also if so, what profile attributes did you keep in OKTA - just email (for sub), any others?
• Any OKTA attributes you had to keep in sync with your own database?