Managing User Data

Background

In our last post we mentioned Corporate Assets, and how these influence areas such as data the user is allowed to see, or how users sign in.

After login, most Corporate Applications need to work out who the End User is based on tokens issued, then look up further data for that user.

Your Company End User Data

If you have a Large Existing Product Base you may end up with a complex setup that looks like this:

  • The Central User Data for identifying users is shared by all products
  • Each product may have additional Product Specific User Data

Products and People

At a software delivery level your overall setup might look like this, where different people are responsible for different software products:

In this setup the product people are forced to use some centralized data but get lots of great security and connectivity features for free.

Central User Data Fields

The Central User Data schema might initially contain fields such as these, which will be delivered to your products as claims:

Field Name Example Value
User Id 12345
Given Name(s) John
Family Name Doe
Email john.doe@mycompany.com

Open Id Connect User Info

Open Id Connect has a built in solution for User Info, so let’s look at it next. We will update our sample SPA to use the additional Open Id Connect standard scopes of ‘profile and ‘email‘:

The extra scopes requested are returned in the JWT Access Token, which now looks as follows:

If we then send this Access Token in a GET request to the Okta User Info Endpoint, we get User Info in the response:

This mechanism is useful, but it may not be a complete solution, since your SPAs and APIs may also need to use additional custom data points.

Multi Tenant Apps

If your software is used by Employees from multiple Companies, you are likely to need to include the User’s Company Id in the Central User Data.

Central User Data Storage

For our Code Sample we are storing both User Data and Passwords in Okta, but the following is perhaps the most flexible option:

  • Store Central User Data in a Custom Database
  • The Authorization Server does a User Data Lookup via this Database 
  • User Credentials are stored separately to User Data

Product Data Schemas

Products often need to store user ids against their business data. If you are building a completely new system you are likely to design your product data to use the user id from the access token:

Field Name Example Value
Order Id 908111
Customer Id 837711
Order Date Time 2017-10-03T13:45:00
Stock Item Id 937212
Quantity 5
Salesperson User Id 12345

However, you may be migrating a large existing product to an OAuth architecture, and this data may have its own Product User Ids:

Field Name Example Value
Order Id 908111
Customer Id 837711
Order Date Time 2017-10-03T13:45:00
Stock Item Id 937212
Quantity 5
Salesperson User Id 119761

In this case you may not want or be able to migrate all primary and foreign keys, and may prefer to use a mapping solution.

Mapping to Product User Ids

If you need to map Product User Ids to Central User Ids, then a simple solution can be to add the Product User Id to the Central Data:

Users Field Name Example Value
User Id 12345
Sales Product User Id 119761
Given Name John
Surname Doe
Email john.doe@mycompany.com

Products can then do some kind of Data Lookup after login – a first effort might look like this:

Mapping to Federated User Ids

In future posts I will discuss Federated Logins, where users log in with an External Identity Provider that supplies External User Ids in tokens.

The good news is that this type of User Mapping is handled by the Authorization Server, so no UI or API code changes will be needed.

Aim to Reduce Domain Pressures

If you work in a large organization, I would recommend some strategic thinking about which data points belong in the central data and which belong in product data.

Some user data can be domain specific and business owners of software products may want to change data points such as User Roles often.

In some companies it will work best to let each product manage their own domain data points, so that we avoid bottlenecks on a central team:

If in doubt, keep the Central User Data small to begin with – you can always extend it later once the basic OAuth Architecture is working well.

Where Are We?

Hopefully this post has helped you think about potential data migration issues when moving to an OAuth Architecture, and how to identify the user to your APIs and UIs after login.

Next Steps