Is oauth/oidc overkill for first-party microservice platforms?

Question

I’m currently working on designing authn/authz for a new micro-services based platform.



My background is in cloud/infrastructure so some of the concepts in this area are new to me but I do have experience in adjacent areas.



In short, I’m trying to understand if oauth/oidc is overkill for us, given that we’re a creating a system composed entirely of 1st party applications. If it is overkill, I’d like to understand what the alternatives are.



The requirements for this platform are quite straightforward - we’d like to leverage Microsoft Entra as an IDP to relieve ourselves of some of the implementation details of managing users (i.e., passwords). We also need to be able to implement fine-grained access control.

I believe that oauth 2.0 was mainly designed for the use case of a 3rd party client connecting to a resource server and therefore requiring consent of the resource owner. Because of this, all clients and all resource servers have to be registered with the authorization server and have their scopes published. Moreover, on each client, one needs to establish the consents needed from the user using the published scopes of the resource server. Also, in Entra, you need to assign users to all apps involved (and optionally some roles if you want RBAC).



The above seems cumbersome/pointless for a few reasons. For one, we may have several resource servers in the future - managing this ever-growing list of consents and scopes will be difficult. Two, the client is a first party application that is already trusted so the consent process seems a bit redundant. Moreover, this client will be serving as a front-end for the entire platform, so it’s likely all scopes will be just full-access anyway. Of note, the client in this case will be a SPA.



It also appears that oauth doesn’t help us achieve fine grained access control. While it’s true that you can assign roles to users in the authorization server, and those claims are accessible in the access tokens, RBAC does not achieve fine-grained access controls itself. We will require another authorization solution like OpenFGA that supports ReBAC to achieve more sophisticated authz capabilities.



For these reasons, I am starting to doubt the need for oauth/oidc, but this is where my knowledge falls short. Is there anything that I'm missing in terms of benefits, even when the platform is entirely first party applications? What other industry accepted practices are there in terms of authn/authz for first party micro services? Is there a simpler way to allow Entra to simply be an IDP, have my users login to it, but then make all authorization decisions via a ReBac tool, thus removing the need to register/manage all applications/scopes/grants in oauth? If so, how exactly does this work from a user flow perspective (user-agent, client, micro service N)?



Thanks!

Answer 1

AUTHORIZATION REQUIREMENT

It sounds like the related design consideration for your microservices is how you will manage authorization.

Many security frameworks only provide authentication, whereas OAuth is an authorization framework.

The main OAuth result is to deliver a useful JWT access token to your APIs in a way that enables scalable business authorization. This works for first party setups and also scales to third party setups when required.

ACCESS TOKEN DESIGN

Access tokens provide scopes and claims that you can use for authorization:

• Scopes can be designed to represent business areas so that each API rejects access tokens that do not match its business area.
• Claims can be any data you want, like a customer ID, tenant ID, region, or a runtime value representing the user's authentication strength.
• Each scope contains one or more claims, and when a client requests a scope its claims are issued to the access token.

MANAGEABILITY

The authorization server should make it easy to manage scopes and claims and disable consent for first party clients. Evaluate whether that is true for your current provider and consider alternatives otherwise.

When using OAuth, aim to only manage a small number of scopes and claims in the authorization server to prevent unwelcome deployment dependencies.

Manage the majority of (fine grained) authorization values in your APIs, like ReBAC relationships. During API requests. derive the fine grained data from access token claims. The access token helps to set up authorization but enforcing rules is the responsibility of your APIs.

ZERO TRUST APPROACH

One approach is to require every microservice to validate a JWT access token on every request. The JWT conveys security context in a secure way that prevents a malicious party calling an API or changing sensitive values.

Microservices can forward JWTs to each other and use OAuth token exchange to vary access token permissions when required.

Benefits include protection against internal threats and enabling any microservice to be exposed to the internet.

OTHER APPROACHES

Another option is something more basic where you invent your own backend message credential, eg a cookie, after an Entra ID login conpletes. You might combine that with infrastructure security to lock down the callers of each microservice.

This type of solution is less complete from an authorization viewpoint. Secure context is often sent in plain HTTP headers that could potentially be exploited.

FUTURE PROOF SECURITY

Ultimately, whether and when to use OAuth depends on your current and future security use cases.

OAuth has a learning curve that you should not underestimate. It is common to start by clarifying requirements and planning a kind of roadmap.

If you get early integrations right you get design patterns to more easily meet other difficult security requirements in future:

• Easily update clients to use newer and more cutting edge authentication methods.
• Onboard users from various external systems, eg business partners, SalesForce etc.