Register an Office Add-in that uses single sign-on (SSO) with the Microsoft identity platform
This article explains how to register an Office Add-in with the Microsoft identity platform so that you can use SSO. Register the add-in when you begin developing it so that when you progress to testing or production, you can change the existing registration or create separate registrations for development, testing, and production versions of the add-in.
The following table itemizes the information that you need to carry out this procedure and the corresponding placeholders that appear in the instructions.
|A human readable name for the add-in. (Uniqueness recommended, but not required.)||
|An application ID which Azure generates for you as part of the registration process.||
|The fully qualified domain name (except for protocol) of the add-in. You must use a domain that you own. For this reason, you cannot use certain well-known domains such as
|The permissions to the Microsoft identity platform and Microsoft Graph that your add-in needs. (
Create an app registration
Registering your application (the add-in) establishes a trust relationship between your add-in and the Microsoft identity platform. The trust is unidirectional: your add-in trusts the Microsoft identity platform, and not the other way around.
Sign in to the Azure portal with the admin credentials to your Microsoft 365 tenancy. For example, MyName@contoso.onmicrosoft.com.
Under Manage, select App registrations > New registration. On the Register an application page, set the values as follows.
- Set Name to
- Set Supported account types to Accounts in any organizational directory (any Azure AD directory - multitenant) and personal Microsoft accounts (e.g. Skype, Xbox).
- Leave Redirect URI empty.
- Choose Register.
- Set Name to
Copy and save the values for the Application (client) ID and the Directory (tenant) ID. You'll use both of them in later procedures.
This ID is the "audience" value when other applications, such as the Office client application (e.g., PowerPoint, Word, Excel), seek authorized access to the application. It is also the "client ID" of the application when it, in turn, seeks authorized access to Microsoft Graph.
Add a client secret
Sometimes called an application password, a client secret is a string value your app can use in place of a certificate to identity itself.
- In the Azure portal, in App registrations, select your application.
- Select Certificates & secrets > Client secrets > New client secret.
- Add a description for your client secret.
- Select an expiration for the secret or specify a custom lifetime.
- Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.
- Microsoft recommends that you set an expiration value of less than 12 months.
- Select Add.
- Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page.
Expose a web API
Be sure you are viewing the app registration you just created.
Under Manage, select Expose an API, and select the Set link. This opens a Set the App ID URI box with a generated Application ID URI in the form
api://<application-id>. Insert your fully qualified domain name before the
<application-id>. The entire ID should have the form
api://<fully-qualified-domain-name>/<application-id>; for example,
If you get an error saying that the domain is already owned but you own it, follow the procedure at Quickstart: Add a custom domain name to Azure Active Directory to register it, and then repeat this step. (This error can also occur if you are not signed in with credentials of an admin in the Microsoft 365 tenancy. See step 2. Sign out and sign in again with admin credentials and repeat the process from step 3.)
Add a scope
Select the Add a scope button. In the panel that opens, enter
access_as_useras the Scope name.
Set Who can consent? to Admins and users.
Fill in the fields for configuring the admin and user consent prompts with values that are appropriate for the
access_as_userscope which enables the Office client application to use your add-in's web APIs with the same rights as the current user. Suggestions:
- Admin consent display name: Office can act as the user.
- Admin consent description: Enable Office to call the add-in's web APIs with the same rights as the current user.
- User consent display name: Office can act as you.
- User consent description: Enable Office to call the add-in's web APIs with the same rights that you have.
Ensure that State is set to Enabled.
Select Add scope.
The domain part of the Scope name displayed just below the text field should automatically match the Application ID URI set in the previous step, with
/access_as_userappended to the end; for example,
In the Authorized client applications section, enter the following ID to pre-authorize all Microsoft Office application endpoints.
ea5a67f6-b6f3-4338-b240-c655ddc3cc8e(All Microsoft Office application endpoints)
ea5a67f6-b6f3-4338-b240-c655ddc3cc8eID pre-authorizes Office on all the following platforms. Alternatively, you can enter a proper subset of the following IDs if for any reason you want to deny authorization to Office on some platforms. Just leave out the IDs of the platforms from which you want to withhold authorization. Users of your add-in on those platforms will not be able to call your Web APIs, but other functionality in your add-in will still work.
93d53678-613d-4013-afc1-62e9e444a0a5(Office on the web)
bc59ab01-8403-45c6-8796-ac3ef710b3e3(Outlook on the web)
Select Add a client application. In the panel that opens, set the Client ID to the respective GUID and check the box for
Select Add application.
Add Microsoft Graph permissions
Under Manage, select Authentication, then choose Add a platform.
In the Configure platforms pane, select Web, and then set the Redirect URI value to
Under Manage, select API permissions, and select Add a permission. On the panel that opens, choose Microsoft Graph, and then choose Delegated permissions.
Use the Select permissions search box to search for the permissions your add-in needs. The following are examples.
User.Readpermission may already be listed by default. It's a good practice to only request permissions that are needed, so we recommend that you uncheck the box for this permission if your add-in does not actually need it.
Select the check box for each permission as it appears (note that the permissions will not remain visible in the list as you select each one). After selecting the permissions that your add-in needs, select the Add permissions button.
Submit and view feedback for