Distinguishing user types in OAuth 2

Question

We're building a system that exposes APIs, subsets of which are accessible to different user types:

• organization administrator users can access relevant admin APIs that give them full access to their data. They are identified via email and a password that they control.
• device registrar users can access certain APIs that should only be accessible to tablets deployed on-site at organizations. They are identified via an email and password that we control. There is a one-time setup process that the organization goes through to register a device, and it involves logging on with the device registrar account and providing some additional metadata. From there, the device caches the OAuth token and automatically renews it using the refresh token.
• visitor users can access APIs that are needed by the end consumer (i.e. the general public), but they must first provide - and prove access to - a mobile number. In other words, they provide a phone number and a OTP will prove they have access to that phone.

We are building this on top of IdentityServer4 using ASP.NET Core and Firestore. We already have IS4 integrated with Firestore and can already authenticate/authorize organization administrators. Each such user in our Firestore database looks like this:

Notice that we just store a set of claims for each user, and in this case it's just an organization ID that the user is an administrator for.

What I'm struggling with a bit is understanding how best to model our other use cases: registered devices and visitors. On the one hand it feels like I could simply use claims to distinguish the different cases; something like this:

• an orgid claim means that user is an organization administrator
• a regordid claim means that user is able to register a device
• a phone claim means that user is a visitor

But on the other hand, this feels a little fragile to me. What if, for example, we wanted both organization administrator users and device registrar users to have the orgid claim? After all, that makes sense because device registrar users are still tied to a specific organization.

On the other hand, is it "normal" to solve this by having some kind of "user type" claim?

Can anyone offer any design tips here?

Answer 1

Good question - some notes below on how I've dealt with this in the past:

MODELLING USERS

By all means model users and their attributes in terms of what makes sense to your company. Then manage this data via some kind of User Service. However, not all user attributes should be included in OAuth access tokens. Aim to avoid a setup where adding Claim X to a token for API 1 also affects tokens for API 2.

OAUTH USER DATA v PRODUCT USER DATA

At some point there is a separation between OAuth User Data and each API's Domain Specific User Data. You perhaps should not really be sending 'device + registrar' claims in tokens to the admin API if the claims are meaningless to the recipient?

CLAIMS BASED ARCHITECTURE

OAuth should enable an architecture where each of your APIs can collect the claims it is interested in, both from the token and from other sources. If interested in this approach, see these resources of mine:

• Authorization Design Blog Post
• Some C# Code that implements this pattern

In your example this would allow you to deal with 'orgid' privileges in a dynamic manner, based on what that means to each API.

PUT EACH API IN CONTROL

I tend to use the Authorization Server as a 'toolbox' with clearly defined boundaries, so that the API architecture can scale without conflicts:

• The Authorization Server's role is to deal only with authentication, and issuing tokens to identify the caller
• Tokens contain only a User Id and OAuth scopes, and are therefore easily sharable between multiple APIs
• The API's role is to collect claims and deal with business authorization, and this tends to involve different domain specific data for each API

Answer 2

You could have two types of claims, admin and user. For admin users, you add the admin claim (if the claim not present the user is not admin).

If the user claim is not there, he is not an user at all. And if none of the admin/user claim is present then he is a guest. This is one approach.