Hi everyone,
I am apologizing in advance if I am asking a duplicate question, but unfortunately I haven’t be able to find my answer here or anywhere so far.
I am working on an asp .net core Rest Api application. The IT team already move everything to Office 365, and now I am trying to figure out how we can authenticate and authorize the user with user-name and password against Azure AD.
The documentation made me so confuse. please correct me if I am wrong:
I know that we use “Connections” to connect Auth0 to Azure AD. But after that, I don’t understand which method should I use to connect my app to Auth0, “Applications” or “APIs”?
If “Applications” which type of application should I use, “Regular web app” or “Machine to Machine application”?
If “APIs” which APIs should I use to log in a user with user-name/password?
I would be appreciate if someone can help me with sequence of process?!?!
Thanks
@mani.jalilian I am not sure if I am missing your question, but it sounds like you are wondering at a high level how the various pieces fall together with OAuth2/OIDC?
There are a few objects to consider:
Connections
As you mentioned these connections model how a user authenticates with Auth0. Your options are authenticate users with username/password, social, IP auth, passwordless, SAML, etc.
Resource Servers and API
You can model your APIs in Auth0 by specifying the unique identifier, format of the JWT and other information. When building an API it really cares about authorization. That is, it wants to receive a token and validate the claims of that token are present, wellformed, valid, and signed by the expected authorization server, etc. The API itself doesn’t do any authentication flows. It simply receives a token to consume. Using that token it determines if the inbound request should be allowed to proceed. You API can use any information it wants to make authorization policies, but it is common to use the scope claim of the JWT.
Clients
These are the applications your users are authenticating with. This is where the application sends you to Auth0 to get an id_token and/or an access_token. The application will consume the id_token or pass the access_token to the /userinfo to get information about the authenticated user. The client uses the access_token to call endpoints on some API to fetch or modify data.
Since users log into application this is where connections are assigned. Whenever a connection is configured for a client/application you are saying any identity in this connection is allowed to log into this client/application.
So it sounds like your RESTful API needs to be modeled as an API in Auth0. Any of the applications you have will be consumers of the API and this is where the connection for Azure AD needs to live. You users would log into that application to get an id_token and access_token. The application will use the id_token or /userinfo endpoint to retrieve information about the logged in user. Anytime that application needs to talk to your RESTful API it will send the access_token as an Authorization: Bearer {{accesss-token}} formatted header for your API to validate.