You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Training guide: App registrations in the Azure portal (legacy)
24
24
25
-
You can find numerous improvements in the new [App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience in the Azure portal. If you're more familiar with the legacy experience, use this training guide to get you started using the new experience.
25
+
You can find many improvements in the new [App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience in the Azure portal. If you're familiar with the App registrations (legacy) experience in the Azure portal, use this training guide to get started using the new experience.
26
26
27
27
In Azure Active Directory, the new application registration experience described here is generally available (GA). In Azure Active Directory B2C (Azure AD B2C), this experience is in preview.
28
28
29
29
## Key changes
30
30
31
-
- App registrations aren't limited to being either a **web app/API** or a **native** app. You can use the same app registration for all of these by registering the respective redirect URIs.
32
-
- The legacy experience supported apps that sign in organizational (Azure AD) accounts only. Apps were registered as single-tenant (supporting only organizational accounts from the directory the app was registered in) and could be modified to be multi-tenant (supporting all organizational accounts). The new experience allows you to register apps that can support both those options as well as a third option: all organizational accounts as well as personal Microsoft accounts.
33
-
- The legacy experience was only available when signed into the Azure portal using an organizational account. With the new experience, you can use personal Microsoft accounts that are not associated with a directory.
31
+
- App registrations aren't limited to being either a *web app/API* or a *native* app. You can use the same app registration for all of these apps by registering the respective redirect URIs.
32
+
33
+
- The legacy experience supported apps that sign in by using organizational (Azure AD) accounts only. Apps were registered as single-tenant. Apps supported only organizational accounts from the directory that the app was registered in. Apps could be modified to be multi-tenant and support all organizational accounts. The new experience allows you to register apps that can support both those options as well as a third option: all organizational accounts as well as personal Microsoft accounts.
34
+
35
+
- The legacy experience was only available when signed into the Azure portal using an organizational account. With the new experience, you can use personal Microsoft accounts that aren't associated with a directory.
34
36
35
37
## List of applications
36
38
37
-
- The new app list shows applications that were registered through the legacy app registrations experience in the Azure portal (apps that sign in Azure AD accounts) as well as apps registered though the [Application Registration Portal](https://apps.dev.microsoft.com/) (apps that sign in Azure AD and personal Microsoft accounts).
38
-
- The new app list doesn't have an **Application type** column (since a single app registration can be several types) and has two additional columns: a **Created on** column and a **Certificates & secrets** column that shows the status (current, expiring soon, or expired) of credentials that have been registered on the app.
39
+
The new app list shows applications that were registered through the legacy app registrations experience in the Azure portal. These apps sign in by using Azure AD accounts. The new app list also shows apps registered though the Application Registration Portal. These apps sign in by using Azure AD and personal Microsoft accounts.
40
+
41
+
>[!NOTE]
42
+
>The Application Registration Portal has been deprecated.
43
+
44
+
The new app list doesn't have an **Application type** column because a single app registration can be several types. The list has two additional columns: **Created on** and **Certificates & secrets**. **Certificates & secrets** shows the status of credentials that have been registered on the app. Statuses include **Current**, **Expiring soon**, and **Expired**.
39
45
40
46
## New app registration
41
47
42
-
In the legacy experience, to register an app you were required to provide: **Name**, **Application type**, and **Sign-on URL/Redirect URI**. The apps that were created were Azure AD only single-tenant applications meaning that they only supported organizational accounts from the directory the app was registered in.
48
+
In the legacy experience, to register an app you were required to provide: **Name**, **Application type**, and **Sign-on URL/Redirect URI**. The apps that were created were Azure AD only single-tenant applications. They only supported organizational accounts from the directory the app was registered in.
49
+
50
+
In the new experience, you must provide a **Name** for the app and choose the **Supported account types**. You can optionally provide a **Redirect URI**. If you provide a redirect URI, you'll need to specify whether it's web/public (mobile and desktop). For more information, see [Quickstart: Register an application with the Microsoft identity platform](quickstart-register-app.md). For Azure AD B2C, see [Register an application in Azure Active Directory B2C](../../active-directory-b2c/tutorial-register-applications.md).
51
+
52
+
## Differences between the Application Registration Portal and App registrations page
43
53
44
-
In the new experience, you must provide a **Name** for the app and choose the **Supported account types**. You can optionally provide a **redirect URI**. If you provide a redirect URI, you'll need to specify if it's web/public (mobile and desktop). For more info on how to register an app using the new app registrations experience, see [Register an app with the Microsoft identity platform](quickstart-register-app.md). For Azure AD B2C, see [Register an application in Azure Active Directory B2C](../../active-directory-b2c/tutorial-register-applications.md).
54
+
### The legacy Properties page
45
55
46
-
## The legacy Properties page
56
+
The legacy experience had a **Properties** page. **Properties** had the following fields:
47
57
48
-
The legacy experience had a **Properties** page that the new experience doesn't have. The **Properties** blade had the following fields: **Name**, **Object ID**, **Application ID**, **App ID URI**, **Logo**, **Home page URL**, **Logout URL**, **Terms of service URL**, **Privacy statement URL**, **Application type**, and **Multi-tenant.**
58
+
-**Name**
59
+
-**Object ID**
60
+
-**Application ID**
61
+
-**App ID URI**
62
+
-**Logo**
63
+
-**Home page URL**
64
+
-**Logout URL**
65
+
-**Terms of service URL**
66
+
-**Privacy statement URL**
67
+
-**Application type**
68
+
-**Multi-tenant**
49
69
50
-
Here's where you can find the equivalent functionality in the new experience:
70
+
The new experience doesn't have that page. Here's where you can find the equivalent functionality:
51
71
52
-
-**Name**, **Logo**, **Home page URL**, **Terms of service URL**, and **Privacy statement URL**is now on the app's **Branding** page.
53
-
-**Object ID** and **Application (client) ID**is on the **Overview** page.
54
-
- The functionality controlled by the **Multi-tenant** toggle in the legacy experience has been replaced by **Supported account types** on the **Authentication** page. For more information about how multi-tenant maps to the supported account type options, see [this quickstart](quickstart-modify-supported-accounts.md).
72
+
-**Name**, **Logo**, **Home page URL**, **Terms of service URL**, and **Privacy statement URL**are now on the app's **Branding** page.
73
+
-**Object ID** and **Application (client) ID**are on the **Overview** page.
74
+
- The functionality controlled by the **Multi-tenant** toggle in the legacy experience has been replaced by **Supported account types** on the **Authentication** page. For more information, see [Quickstart: Modify the accounts supported by an application](quickstart-modify-supported-accounts.md).
55
75
-**Logout URL** is now on the **Authentication** page.
56
-
-**Application type** is no longer a valid field. Instead, redirect URIs (which you can find on the **Authentication** page) determine which app types are supported.
57
-
-**App ID URI** is now called **Application ID URI** and you can find this on the **Expose an API** blade. In the legacy experience, this property was auto-registered using the following format: `https://{tenantdomain}/{appID}` (for example, `https://microsoft.onmicrosoft.com/aeb4be67-a634-4f20-9a46-e0d4d4f1f96d`). In the new experience, it's auto-generated as `api://{appID}`, but it needs to be explicitly saved. In Azure AD B2C tenants, the `https://{tenantdomain}/{appID}` format is still used.
76
+
-**Application type** is no longer a valid field. Instead, redirect URIs, which you can find on the **Authentication** page, determine which app types are supported.
77
+
-**App ID URI** is now called **Application ID URI** and you can find it on **Expose an API**. In the legacy experience, this property was autoregistered using the following format: `https://{tenantdomain}/{appID}`, for example, `https://microsoft.onmicrosoft.com/492439af-3282-44c3-b297-45463339544b`. In the new experience, it's autogenerated as `api://{appID}`, but it needs to be explicitly saved. In Azure AD B2C tenants, the `https://{tenantdomain}/{appID}` format is still used.
78
+
79
+
### Reply URLs/redirect URls
80
+
81
+
In the legacy experience, an app had a **Reply URLs** page. In the new experience, reply URLs can be found on an app's **Authentication** page. They're now referred to as **Redirect URIs**.
82
+
83
+
The format for redirect URIs has changed. They're required to be associated with an app type, either web or public. For security reasons, wildcards and `http://` schemes aren't supported, except for *http://localhost*.
84
+
85
+
### Keys/Certificates & secrets
86
+
87
+
In the legacy experience, an app had **Keys** page. In the new experience, it has been renamed to **Certificates & secrets**.
88
+
89
+
**Public keys** are now referred to as **Certificates**. **Passwords** are now referred to as **Client secrets**.
58
90
59
-
##Reply URLs/redirect URls
91
+
### Required permissions/API permissions
60
92
61
-
In the legacy experience, an app had a **Reply URLs** page. In the new experience, Reply URLs can be found on an app's **Authentication** section. In addition, they are referred to as **Redirect URIs**. In addition, The format for redirect URIs has changed. They are required to be associated with an app type (web or public). In addition, for security reasons, wildcards and http:// schemes are not supported (with the exception of http://localhost).
93
+
In the legacy experience, an app had a **Required permissions** page. In the new experience, it has been renamed to **API permissions**.
62
94
63
-
## Keys/Certificates & secrets
95
+
When you selected an API in the legacy experience, you could choose from a small list of Microsoft APIs. You could also search through service principals in the tenant. In the new experience, you can choose from multiple tabs: **Microsoft APIs**, **APIs my organization uses**, or **My APIs**. The search bar on **APIs my organization** uses tab searches through service principals in the tenant.
64
96
65
-
In the legacy experience, an app had **Keys** page. In the new experience, it has been renamed to **Certificates & secrets**. In addition, **Public keys** are referred to as **Certificates** and **Passwords** are referred to as **Client secrets**.
97
+
> [!NOTE]
98
+
> You won't see this tab if your application isn't associated with a tenant. For more information on how to request permissions, see [Quickstart: Configure a client application to access web APIs](quickstart-configure-app-access-web-apis.md).
66
99
67
-
## Required permissions/API permissions
100
+
The legacy experience had a **Grant permissions** button at the top of the **Requested permissions** page. In the new experience, the **Grant consent** page has a **Grant admin consent** button on an app's **API permissions** section. There are also some differences in the ways the buttons function.
68
101
69
-
- In the legacy experience, an app had a **Required permissions** page. In the new experience, it has been renamed to **API permissions**.
70
-
- When selecting an API in the legacy experience, you could choose from a small list of Microsoft APIs or search through service principals in the tenant. In the new experience, you can choose from multiple tabs: **Microsoft APIs**, **APIs my organization uses**, or **My APIs**. The search bar on **APIs my organization** uses tab searches through service principals in the tenant.
102
+
In the legacy experience, the logic varied depending on the signed in user and the permissions being requested. The logic was:
71
103
72
-
> [!NOTE]
73
-
> You won't see this tab if your application isn't associated with a tenant. For more info on how to request permissions using the new experience, see [this quickstart](quickstart-configure-app-access-web-apis.md).
104
+
- If only user consent-able permissions were being requested and the signed in user wasn't an admin, the user could grant user consent for the requested permissions.
105
+
- If at least one permission that requires admin consent was requested and the signed in user wasn't an admin, the user got an error when attempting to grant consent.
106
+
- If the signed in user was an admin, admin consent was granted for all the requested permissions.
74
107
75
-
- The legacy experience had a **Grant permissions** button at the top of the **Requested permissions** page. In the new experience, there's a **Grant consent** section with a **Grant admin consent** button on an app's **API permissions** section. In addition, there are some differences in the ways the buttons function:
76
-
- In the legacy experience, the logic varied depending on the signed in user and the permissions being requested. The logic was:
77
-
- If only user consent-able permissions were being requested and the signed in user was not an admin, the user was able to grant user consent for the requested permissions.
78
-
- If at least one permission that requires admin consent was being requested and the signed in user was not an admin, the user got an error when attempting to grant consent.
79
-
- If the signed in user was an admin, admin consent was granted for all the requested permissions.
80
-
- In the new experience, only an admin can grant consent. When an admin selects the **Grant admin consent** button, admin consent is granted to all the requested permissions.
108
+
In the new experience, only an admin can grant consent. When an admin selects **Grant admin consent**, admin consent is granted to all the requested permissions.
81
109
82
110
## Deleting an app registration
83
111
84
-
In the legacy experience, an app had to be single-tenant to be deleted. The delete button was disabled for multi-tenant apps. In the new experience, apps can be deleted in any state, but you must confirm the action. For more information about deleting app registrations, see [this quickstart](quickstart-remove-app.md).
112
+
In the legacy experience, you could delete only single-tenant apps. The delete button was disabled for multi-tenant apps. In the new experience, you can delete apps in any state, but you must confirm the action. For more information, see [Quickstart: Remove an application registered with the Microsoft identity platform](quickstart-remove-app.md).
85
113
86
114
## Application manifest
87
115
88
-
The legacy and new experiences use different versions for the format of the JSON in the manifest editor. For more info, see [Application manifest](reference-app-manifest.md).
116
+
The legacy and new experiences use different versions for the format of the JSON in the manifest editor. For more information, see [Azure Active Directory app manifest](reference-app-manifest.md).
89
117
90
118
## New UI
91
119
92
-
There's new UI for properties that could previously only be set using the manifest editor or the API, or didn't exist.
120
+
The new experience adds UI controls for the following properties:
93
121
94
-
-**Implicit grant flow** (oauth2AllowImplicitFlow) can be found on the **Authentication** page. Unlike in the legacy experience, you can enable **access tokens** or **id tokens**, or both.
95
-
-**Scopes defined by this API** (oauth2Permissions) and **Authorized client applications** (preAuthorizedApplications) can be configured through the **Expose an API** page. For more info on how to configure an app to be a web API and expose permissions/scopes, see [this quickstart](quickstart-configure-app-expose-web-apis.md).
96
-
-**Publisher domain** (which is displayed to users on the [application's consent prompt](application-consent-experience.md)) can be found on the **Branding blade** page. For more info on how to configure a publisher domain, see [this how-to](howto-configure-publisher-domain.md).
122
+
-The **Authentication** page has **Implicit grant flow** (`oauth2AllowImplicitFlow`). Unlike in the legacy experience, you can enable **Access tokens** or **ID tokens**, or both.
123
+
-The **Expose an API** page contains **Scopes defined by this API** (`oauth2Permissions`) and **Authorized client applications** (`preAuthorizedApplications`). For more information on how to configure an app to be a web API and expose permissions/scopes, see [Quickstart: Configure an application to expose web APIs](quickstart-configure-app-expose-web-apis.md).
124
+
-The **Branding** page contains the **Publisher domain**. The publisher domain is displayed to users on the [application's consent prompt](application-consent-experience.md). For more information, see [How to: Configure an application's publisher domain](howto-configure-publisher-domain.md).
0 commit comments