Can I use a single app registration for both provider and client roles in Azure AD?

Question

Hi, I'm seeking guidance on Azure AD app registrations.

My current setup is as follows:

• Separate client and provider app registrations
• Client app uses its client ID and secret to access the provider app registration
• Provider app registration issues a JWT token
• Client has a role assigned by the provider app registration

Is it possible to consolidate this into a single app registration that functions as both provider and client?

Can this single app registration:

1. Act as its own provider and client (using its own client id, client secret and scope), issuing JWT tokens?
2. Use its own defined roles for self-access?

Additional Considerations

• What are the key considerations or potential drawbacks?
• Are there any best practices or security implications to be aware of when implementing such a setup?
• We are checking the JWT token on aud, iss and whether the JWT token is issued by microsoft.

Any insights or documentation references would be greatly appreciated.

Answer 1

Hi @Melvin Tran

Thank you for posting this in Microsoft Q&A.

I understand that you currently have two separate applications for client and provider, and you are concerned about the feasibility of merging them into a single application.

Yes, it is possible to consolidate your current setup into a single app registration that functions as both provider and client. By setting up a single app registration, you can configure it to function in both roles. This allows you to utilize the app registration's client ID and secret to access its own API and generate JWT tokens. Additionally, you can establish roles for the app registration and use them for self-access.

By registering both the client application and provider in Microsoft Entra, you can leverage its authentication capabilities to secure access to your web API. This process ensures that only authorized clients have access to the provider application. The two app registrations are interconnected, with the client app having various permission types and the provider offering different scopes accessible by the client application.

key considerations or potential drawbacks

1.By having a single app registration handle both client and provider functions, you may be increasing the attack surface. If the app registration is compromised, an attacker could gain access to both the client and provider functionality.

2.With the app registration using its own defined roles for self-access, there is a risk of role confusion or misconfiguration, which could lead to unauthorized access or privilege escalation.

To mitigate the potential drawbacks, ensure that the app registration only has the necessary permissions and roles to perform its functions, reducing the risk of privilege escalation.

For your reference : https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-access-web-apis

Hope this helps. Do let us know if you any further queries.

Thanks,

Navya.

Please remember to "Accept Answer" if answer helped you. This will help us as well as others in the community who might be researching similar questions.