Securing a multi-tenant API with SSO and different roles per tenant

Question

I am working on developing a REST API that will be used by first party clients that we develop, and third party clients in the future. The first party clients include a SPA client side application, and programs that run on client PC's (can't guarantee security of secrets).

Furthermore, this API is pseudo-multitenant. We have multiple tenants, and each tenant can have one or more active instances in the API, each with it's own set of security roles, each with varying permissions. All of this data however is stored in the same database, and we want the ability to allow users to switch the instance they're working on (both in-tenant, and out-of-tenant). Sign in CAN be allowed using third party providers (Facebook/Google/etc). Also, their sign-in should allow them to access the other instances without re-authenticating.

I'm getting a little confused on exactly how I should be implementing the authentication/authorization logic given the multi-tenant/multi-roles nature of the API. What I am thinking the right path is to implement OpenID Connect authentication to the API, and then OAuth to delegate the access to the specific instances that the user is attempting to. My confusion comes into play when I attempt to determine what tokens should be in use where. We want the ability for our users to remain signed in to the SPA, and still change their instance.

I've seen information on securing multitenant/multidatabase REST api's, but the roles appear to be consistent, so I can't extrapolate the handling to one database with various roles.

So these are my questions:

• Is it correct to use OpenID Connect and OAuth2 given this information?
• It appears that OpenID Connect allows for advertising the scopes that you wish to delegate. How would this be handled with roles indeterminate until after authentication and when their tenant is known?
• Is it correct to delegate the individual permissions via OAuth (what I want to do), or should OAuth just delegate their assigned roles per instance, and the application then have to lookup the permissions?
• Should there be two separate tokens, one for general authentication, and one for the authorization per instance? What would be the standard for passing these to the API. Currently we are using JWT and an Authorization Bearer header. I like the simplicity of one token, but if that needs to be adjusted, amended, we can do that.

I have been searching for articles for the past week or two on this, but haven't found anything to help clarify what type of flow would be best for my situation and how I handle the variability from instance to instance. If you think I've missed an article, please feel free to add it to this as a comment and I'll review it as well.

Answer 1

I'm not a programmer, but I have reviewed an org that seems to do something similar. Here's how they do it...

AngularJS client authenticates with an application security API we have via OAuth. The system hosting the API then passes the authentication and requests the authorization from a second system. The second system returns the authZ token, username, and claims to the security API system. The security API calls to a token manager system that creates a JWT and returns it to the security API system. Finally, the security API returns the encoded JWT to the AngularJS client.

An individual call goes from the AngularJS client to the actual application API, providing the token. The application API system gives the token to the token manager for validation. If valid, the API returns data (or throws on invalid or expired tokens).

For renewal, the AngularJS client contacts the security API again, which contacts the authZ token system, returning the renewed token to the security API system, which send it to the token manager for creation of a new JWT, which the security API returns to the client.

At change of tenant, it does an authZ token transfer request call to the security API that goes all the way to the authZ token server, a new authZ token is created and sent back to the security API along with username and roles, it requests a JWT with that, and once returned, passes it to the client.

To more directly answer your questions...

• It seems correct to use OAuth and OIDC
• I don't know about scope advertizing.
• I'm in security, so I'm a fan of role-based access control for everything. :-D So I'd say to have the application do the individual perm lookups from the roles embedded in the token.
• Two separate tokens appears to be how this org deals with it. One, which seems to function as both identity and session ID. The second is the JWT which includes that first token and the roles/claims for the current tenant.