Configure an OpenID Connect OAuth application from Microsoft Entra app gallery
Process of adding an OpenID application from the gallery
Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
Browse to Identity > Applications > Enterprise applications.
Select New application on the top of the dialog box.
In the search box, type the application name. Select the desired application from the result panel, and sign up to the application.
In the Application name page, click on Sign up button.
Note
Here the tenant admin should select the sign-up button and provide the consent to the application. The application is then added to the external tenant, where you can do the configurations. There's no need to add the application explicitly.
You're redirected to the Application Login page or Microsoft Entra ID page for sign-in credentials.
After successful authentication, you accept the consent from the consent page. After that, the application home page appears.
Note
You can add only one instance of the application. If you have already added one and tried to provide the consent again, it will not be added again in the tenant. So logically, you can use only one app instance in the tenant.
Follow the below video to add an OpenID application from the gallery.
Authentication flow using OpenID Connect
The most basic sign-in flow contains the following steps:
Multitenant application
A multitenant application is intended for use in many organizations, not just one organization. These are typically software-as-a-service (SaaS) applications written by an independent software vendor (ISV).
Multitenant applications need to be provisioned in each directory where they'll be used. They require user or administrator consent to register them. This consent process starts when an application has been registered in the directory and is given access to the Graph API or perhaps another web API. When a user or administrator from a different organization signs up to use the application, a dialog box displays the permissions that the application needs.
The user or administrator can then consent to the application. The consent gives the application access to the stated data, and finally registers the application in the directory.
Note
If you're making your application available to users in multiple directories, you need a mechanism to determine which tenant they're in. A single-tenant application only needs to look in its own directory for a user. A multitenant application needs to identify a specific user from all the directories in Microsoft Entra ID.
To accomplish this task, Microsoft Entra ID provides a common authentication endpoint where any multitenant application can direct sign-in requests, instead of a tenant-specific endpoint. This endpoint is https://login.microsoftonline.com/common for all directories in Microsoft Entra ID. A tenant-specific endpoint might be https://login.microsoftonline.com/contoso.onmicrosoft.com.
The common endpoint is important to consider when you're developing your application. You'll need the necessary logic to handle multiple tenants during sign-in, sign-out, and token validation.
By default, Microsoft Entra ID promotes multitenant applications. They're easily accessed across organizations, and they're easy to use after you accept the consent.
Consent framework
You can use the Microsoft Entra consent framework to develop multitenant web and native client applications. These applications allow sign-in by user accounts from a Microsoft Entra tenant, different from the one where the application is registered. They might also need to access web APIs such as:
- The Microsoft Graph API, to access Microsoft Entra ID, Intune, and services in Microsoft 365.
- Other Microsoft services' APIs.
- Your own web APIs.
The framework is based on a user or an administrator giving consent to an application that asks to be registered in their directory. The registration might involve accessing directory data. After consent is given, the client application can call the Microsoft Graph API on behalf of the user, and use the information as needed.
The Microsoft Graph API provides access to data in Microsoft 365, like:
- Calendars and messages from Exchange.
- Sites and lists from SharePoint.
- Documents from OneDrive.
- Notebooks from OneNote.
- Tasks from Planner.
- Workbooks from Excel.
The Graph API also provides access to users and groups from Microsoft Entra ID and other data objects from more Microsoft cloud services.
The following steps show you how the consent experience works for the application developer and user:
Assume you have a web client application that needs to request specific permissions to access a resource or API. The Azure portal is used to declare permission requests at configuration time. Like other configuration settings, they become part of the application's Microsoft Entra registrations. For the Permission request path you need the follow the below steps:
a. Click on the App registrations from the left side of menu and open your application by typing the application name in search box.
b. Click View API Permissions.
c. Click on Add a permission.
d. Click On Microsoft Graph.
e. Select required options from Delegated permissions and Application Permissions.
Consider that your application's permissions have been updated. The application is running, and a user is about to use it for the first time. First the application needs to get an authorization code from the Microsoft Entra ID /authorize endpoint. The authorization code can then be used to acquire a new access and refresh token.
If the user is not already authenticated, the Microsoft Entra ID /authorize endpoint prompts for sign-in.
After the user has signed in, Microsoft Entra ID determines if the user needs to be shown a consent page. This determination is based on whether the user (or their organization's administrator) has already granted the application consent.
If consent has not been granted, Microsoft Entra prompts the user for consent and displays the required permissions that it needs to function. The permissions that are displayed in the consent dialog box match the ones selected in the delegated permissions.
A regular user can consent to some permissions. Other permissions require a tenant administrator's consent.
Difference between admin consent and user consent
As an administrator, you can also consent to an application's delegated permissions on behalf of all the users in your tenant. Administrative consent prevents the consent dialog box from appearing for every user in the tenant. Users who have the administrator role can provide consent. Select Manage > API permissions. Under Grant consent, select Grant admin consent for.
Note
Granting explicit consent by using the Grant admin consent button is now required for single-page applications (SPAs) that use MSAL.js. Otherwise, the application fails when the access token is requested.
App-only permissions always require a tenant administrator's consent. If your application requests an app-only permission and a user tries to sign in to the application, an error message appears. The message says the user isn't able to consent.
If your application uses permissions that require admin consent, you need to have a gesture such as a button or link where the admin can start the action. The request that your application sends for this action is the usual OAuth2/OpenID Connect authorization request. This request includes the prompt=admin_consent query string parameter.
After the admin has consented and the service principal is created in the customer's tenant, later sign-in requests don't need the prompt=admin_consent parameter. Because the administrator has decided that the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.
A tenant administrator can disable the ability for regular users to consent to applications. If this capability is disabled, admin consent is always required for the application to be used in the tenant. If you want to test your application with end-user consent disabled, you can find the configuration switch in the Azure portal. It's in the User settings section under Enterprise applications.
The prompt=admin_consent parameter can also be used by applications that request permissions that don't require admin consent. An example is an application that requires an experience where the tenant admin "signs up" one time, and no other users are prompted for consent from that point on.
Imagine that an application requires admin consent, and an admin signs in without the prompt=admin_consent parameter being sent. When the admin successfully consents to the application, it applies only for their user account. Regular users will still be unable to sign in or consent to the application. This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users' access.
Next steps
Set up OIDC-based single sign-on (SSO) for an application in your Microsoft Entra tenant