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.