Azure AD Authentication for same application in multiple environment

Question

Good Evening,

I have been working on an application where I used Azure AD for the Authentication and database level checking for the authorization. In our application, we used Angular as UI and Web API for business management.

Now I want to understand, the best approach to manage the Azure AD registration process for each environment like dev, QA, UAT, and prod whether all addresses as a Reply URL at the same time or separate -2 for each environment.

Answer 1

@Navneet Kumar , Thank you for reaching out. You can do both, like:

1. Create separate app registrations for each of the environments like UAT, DEV, PROD etc and keep the same redirect URLs in each of them or separate redirect URLs based on your application's configuration. This is something that I would prefer personally, to keep all the app registrations separate for all the environment to reduce complexity.
2. Keep one App Registration and use that same appID and appSecret and Redirect URL in all the other environments. This is feasible if the redirect URL for this app remains a single one for all the environments.

But for me in a situation like this I would go with the first option always, for better management. One instance I can put up is as, suppose in the Dev environment, the app developer decides to introduce a new feature in the app, that would need new permissions to be added in the app registration, but you dont know its impact yet. If you are keeping just one app registration which is referred by both you Dev and PROD environment, that any changes made by your developer would surely get your PROD in a down state. So always advisable, keep things separate and distinct.

Hope this helps.

Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

Answer 2

@Navneet Kumar , The steps remain pretty much the same, but still you can take a look at the steps mentioned below:

1. You develop a WebAPI in your organization that you want to protect by AAD and hence you do an application registration in AAD.
2. After the app registration, you need to go to the "Expose as an API" and set the Identifier URI for this application (default: api://<client_id>)
3. While you set the identifier URIs you also specify the permissions and what type of permissions like either delegated permissions (user permissions) or application permissions.
4. Now comes you actual application that would be calling this api, hence you need to make another app registration for this application in AAD.
5. Under the "API Permissions blade" you need to add you API and set the required permissions.
6. From you application, then you can call the API.

This the overall flow. Now, lets discuss the authentication flow here.

1. The user first accesses the application and then tries to signin, since the application is also protected by AAD, hence user has to authenticate against AAD by one of the OAuth flows as coded in the application. Mostly it would be the Auth-Code-Grant Flow.
2. Once the user gets authenticated by AAD, AAD would issue an access token to the user so that that access token can be submitted to the application to prove the user's authenticity.
3. Now comes the part where the api would be called, it depends whether the api would be called by the user or by the application and based on that another token request would be made to AAD to get the token for the api.
4. Once AAD provides that token the token would be submitted to the WebAPI, Web API validates it and authorizes the access to the user/application with the data being requested for.

Hope this helps.

Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

Answer 3

You need to point to the right instance of the application, either you are running locally on your desktop or on azure webapps. Because when AAD post the response, your application has be verify against the authority it has configured for.