CODEWITHSUNDEEP
asp.net-mvcazureazure-active-directory
amplifier
amplifier

Reputation: 1833

Azure active directory application registration for localhost and production

I successfully registered my ASP.NET MVC application to work with Azure AD. Currently the Sign-on URL parameter (Azure Active Directory->App registrations->New Application Registration) looks like https://localhost:44302/

But for production it apparently will be another (say, https://mycoolapp.com)

How should set up the application so that I could use Azure AD locally (for ex. for debugging) and in production.

Changing the Sign-on URL parameter every time doesn't seem to be a good option.

Upvotes: 7

Views: 5003

Answers (2)

Martin Brandl
Martin Brandl

Reputation: 59001

I would specify the production URL as the Sign-on URL and the production + localhost as the redirect-URL (since you can add multiple redirect-urls!).

See: Register a new application using the Azure portal

Upvotes: 1

Rohit Saigal
Rohit Saigal

Reputation: 9684

Firstly, you can make it work easily without changing sign-on URL every time. You just need to make sure that both URLs.. i.e. https://localhost:44302/ as well as https://mycoolapp.com are available in the Reply URLs for this application.

The value for Sign-on URL that you give at the time of creating app registration goes into two places. It becomes the Home Page URL under Properties for your web application and it also gets added as the first URL in the Reply URLs collection for your web application. Just make sure to add a the second URL to the Reply URLs collection after your app is registered and that's all.

enter image description here

enter image description here

On a side note, even though you can make things work with a single app registration for both production and localhost debugging, you may want to think about having two separate application registrations for production v/s local development and give permissions to production application only for administrators/dev ops if it makes sense.

Imagine any sensitive settings, like if you are using a secret key for your web application, you may not want your development team to have access to secret key for your production app registration even while debugging code. You can always change which app registration gets used in dev v/s production code based on configurations.

It's some of the headaches like these where Managed Service Identities are very appropriate, but whether that makes sense or not is a little different discussion than this one.

Upvotes: 4

Related Questions