[转]Register an application

注册应用程序 - Training | Microsoft Learn

本文转自：Register an application - Training | Microsoft Learn

 

注册应用程序

已完成100 XP

• 12 分钟

注册应用程序会在应用与 Microsoft 标识平台之间建立信任关系。 信任是单向的：应用信任 Microsoft 标识平台，但标识平台并不信任应用。

1. 使用管理员帐户登录到 Microsoft Entra 管理中心 。

2. 打开门户菜单，然后选择“标识”。

3. 在“标识”菜单上的“应用程序”下，选择“应用注册”。

4. 在“应用注册”页面上的菜单中，选择“+新建注册”。

5. 在“注册应用程序”对话框中，使用默认值注册一个名为”演示应用”的应用。 无需输入重定向 URI。

   

6. 完成后，你将转到“演示应用”屏幕。

添加重定向 URI

重定向 URI 是 Microsoft 标识平台重定向用户客户端并在身份验证后发送安全令牌的位置。 例如，在生产 Web 应用中，重定向 URI 通常是在其中运行应用的公共终结点。 在开发过程中，通常还会添加用于在本地运行应用的终结点。

配置已注册的应用程序的平台设置来添加和修改它的重定向 URI。

配置平台设置

在 Azure 门户的“平台配置”中配置每种应用程序类型的设置（包括重定向 URI）。 某些平台（例如 Web 和单页应用程序）要求手动指定重定向 URI。 对于其他平台（例如移动和桌面），可选择在配置其他设置时为用户生成的重定向 URI。

要根据面向的平台或设备配置应用程序设置，请执行以下操作：

1. 在 Azure 门户中的“应用注册”中选择你的应用程序。

2. 在“管理”下，选择“身份验证”。

3. 在“平台配置”下，选择“添加平台”。

4. 在“配置平台”中，为应用程序类型（平台）选择磁贴，以配置其设置。

   

    

   平台	配置设置
   Web	输入应用的重定向 URI，即 Microsoft 标识平台重定向用户客户端并在身份验证后发送安全令牌的位置。 为服务器上运行的标准 Web 应用程序选择此平台。
   单页应用程序	输入应用的重定向 URI，即 Microsoft 标识平台重定向用户客户端并在身份验证后发送安全令牌的位置。 若要在 JavaScript 中或使用 Angular、Vue.js、React.js 或 Blazor WebAssembly 等框架构建客户端 Web 应用，请选择此平台。
   iOS/macOS	输入应用捆绑 ID（在 XCode 中的 Info.plist 内或在生成设置中）。在指定捆绑 ID 时，会为你生成一个重定向 URI。
   Android	输入应用包名称（可在 AndroidManifest.xml 文件中找到），然后生成并输入签名哈希。在指定这些设置时，会为你生成一个重定向 URI。
   移动和桌面应用程序	选择一个建议的重定向 URI，或者指定一个自定义重定向 URI。对于桌面应用程序，建议查看 https://login.microsoftonline.com/common/oauth2/nativeclient。对于未在使用最新版 Microsoft 身份验证库 (MSAL) 或未在使用代理的移动应用程序，请选择此平台。 同时也为桌面应用程序选择此平台。

5. 选择“配置”以完成平台配置。

添加凭据

凭据供访问 Web API 的机密客户端应用程序使用。 Web 应用、其他 Web API、服务类型的应用程序和守护程序类型的应用程序都是机密客户端。 通过凭据，应用程序可以自己的身份进行身份验证，无需用户在运行时进行任何交互。

可将证书和客户端密码（字符串）作为凭据添加到机密客户端应用注册。

添加证书

证书有时被称为公钥，它们是推荐的凭据类型，因为它们提供的保证级别比客户端密码高。 使用受信任的公共证书时，可使用“证书和密码”功能添加证书。 证书必须是以下文件类型之一：.cer、.pem、.crt。

添加客户端密码

客户端密码也称为应用程序密码，它是应用可用于代替证书来标识自身的一个字符串。 在这两种凭据类型中，它使用起来更加轻松。 它常常在开发过程中使用，但它的安全性不如证书。 应在生产环境中运行的应用程序中使用证书。

1. 在 Azure 门户中的“应用注册”中选择你的应用程序。
2. 选择“证书和密码”，然后选择“新建客户端密码”。
3. 添加客户端密码的说明。
4. 选择持续时间。
5. 选择 “添加”。
6. 记录密码的值，以供在客户端应用程序代码中使用；离开此页面后，它将永不再显示。

注册 Web API

若要提供对 Web API 中资源的范围受限访问权限，必须先向 Microsoft 标识平台注册该 API。

1. 执行上述步骤。
2. 跳过“添加重定向 URI”和“配置平台设置”部分。 无需为 Web API 配置重定向 URI，因为没有用户以交互方式进行登录。
3. 暂时跳过“添加凭据”部分。 仅当你的 API 访问下游 API 时，它才需要其自己的凭据 - 本文未涵盖这一方案。

注册 Web API 后，便可添加范围，API 的代码可使用这些范围向 API 的使用者提供具体权限。

添加范围

客户端应用程序中的代码通过将访问令牌及其请求传递到受保护的资源 (Web API) 来请求执行由 Web API 定义的操作的权限。 然后，仅当 Web API 接收的访问令牌包含操作所需的范围（也称为应用程序权限）时，该 API 才会执行请求的操作。

首先，请按照以下步骤创建一个名为 Employees.Read.All 的示例范围：

1. 登录到 Azure 门户。

2. 如果有权访问多个租户，请使用顶部菜单中的“目录 + 订阅”筛选器，选择包含你的客户端应用注册的租户。

3. 依次选择“Microsoft Entra ID”和“应用注册”，然后选择 API 的应用注册。

4. 依次选择“公开 API”、“添加范围”。

   

5. 如果尚未配置应用程序 ID URI，系统会提示你设置一个。 应用 ID URI 充当你将在 API 代码中引用的范围的前缀，它必须是全局独一无二的。 你可以使用提供的默认值（格式为 api://）或指定更具可读性的 URI，例如 https://contoso.com/api。

6. 接下来，在“添加范围”窗格中指定范围的属性。 对于本演练，你可以使用示例值或指定自己的值。

    

   字段	描述	例
   范围名称	范围的名称。 公共范围命名约束为 resource.operation.constraint。	Employees.Read.All
   谁可以同意	管理员选择这个范围是否可以得到用户同意，或者是否需要管理员同意。 要获得更高特权，请选择“仅管理员”。	管理员和用户
   管理员同意显示名称	仅管理员可以看到的范围用途的简短说明。	对员工记录的只读访问权限
   管理员同意说明	仅管理员可以看到的范围所授予权限的更详细说明。	允许应用程序对所有员工数据进行只读访问。
   用户同意显示名称	范围用途的简短说明。 只有当你设置了“谁可以同意管理员和用户”时才会显示给用户。	对员工记录的只读访问权限
   用户同意说明	范围所授予权限的更详细说明。 只有当你设置了“谁可以同意管理员和用户”时才会显示给用户。	允许应用程序对员工数据进行只读访问。

7. 将“状态”设置为“启用”，然后选择“添加范围”。

8. （可选）要取消向应用用户提示同意你定义的范围，可以预授权客户端应用程序访问 Web API。 请仅预授权所信任的客户端应用程序，因为用户不会有机会拒绝同意。

   1. 在“授权的客户端应用程序”下，选择“添加客户端应用程序”。
   2. 输入要预授权的客户端应用程序的“应用程序(客户端) ID”。 例如，以前注册的 Web 应用程序的 ID。
   3. 在“授权的范围”下，选择要取消显示同意提示的范围，然后选择“添加应用程序”。
   4. 如果按照此可选步骤操作，客户端应用现在就是一个预授权的客户端应用 (PCA)；当用户登录它时，系统将不提示用户授予同意。

添加需要管理员同意的范围

接下来，再添加一个名为 Employees.Write.All 的示例范围，只有管理员才能同意该范围。 需要管理员同意的范围通常用于提供对更高特权的操作的访问权限，通常由作为后端服务运行的客户端应用程序或不以交互方式登录用户的后台程序使用。

若要添加 Employees.Write.All 示例范围，请按照上述步骤操作，在“添加范围”窗格中指定以下值：

 

字段	示例值
范围名称	Employees.Write.All
谁可以同意	仅管理员
管理员同意显示名称	对员工记录的写入访问权限
管理员同意说明	允许应用程序对所有员工数据进行写入访问。
用户同意显示名称	无（留空）
用户同意说明	无（留空）

验证公开的范围

如果已成功添加先前部分中所介绍的两个示例范围，则它们将显示在 Web API 的应用注册的“公开 API”窗格中，类似于以下内容：

如图所示，范围的完整字符串由 Web API 的“应用程序 ID URI”与范围的“范围名称”串联而成。

例如，如果 Web API 的应用程序 ID URI 为 https://contoso.com/api，范围名称为 Employees.Read.All，则完整范围为：

https://contoso.com/api/Employees.Read.All

使用公开的范围

接下来，你将按照上述步骤配置客户端应用的注册，其中包含对 Web API 的访问权限和你所定义的范围。

向客户端应用注册授予访问 Web API 的权限后，Microsoft 标识平台可向客户端颁发 OAuth 2.0 访问令牌。 当客户端调用 Web API 时，它会提供一个访问令牌，令牌的范围 (scp) 声明设置为你在客户端的应用注册中所指定的权限。

以后可以根据需要公开其他范围。 请考虑 Web API 可以公开与多个操作关联的多个范围。 在运行时，资源可通过评估其收到的 OAuth 2.0 访问令牌中的范围 (scp) 声明，来控制对 Web API 的访问。

后台发生的情况

• 应用注册是在主租户中创建的
• 应用将在 Microsoft Entra ID 中通过安全主体实例化
• 根据公开的 API 的设置，安全主体由第一位用户或管理员授予许可
• 当用户访问应用程序并使用 API 时，安全主体会被授予安全令牌

---

下一单元: 为应用程序配置权限

 

 

 

 

Plan your line of business application registration strategy - Training | Microsoft Learn

 

1. Learn 
 
2. Training 
 
3. Browse 
 
4. SC-300: Implement Access Management for Apps 
 
5. Implement app registration 

 

 

Register an application

Completed100 XP

• 12 minutes

Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: Your app trusts the Microsoft identity platform—not the other way around.

1. Sign in to the Microsoft Entra admin center using an Administrator account.

2. Open the portal menu and then select Identity.

3. On the Identity menu, under Applications, select App registrations.

4. On the App registrations page, on the menu, select + New registration.

5. On the register an application dialog, register an app named Demo app using the default values. You don't need to enter the redirect URI.

   

6. When complete, you'll be directed to the Demo app screen.

Add a redirect URI

A redirect URI is the location where the Microsoft identity platform redirects a user's client and sends security tokens after authentication. In a production web application, for example, the redirect URI is often a public endpoint where your app is running. During development, it's common to also add the endpoint where you run your app locally.

Add and modify redirect URIs for your registered applications by configuring their platform settings.

Configure platform settings

Settings for each application type, including redirect URIs, are configured in Platform configurations in the Azure portal. Some platforms, like Web and Single-page applications, require you to manually specify a redirect URI. For other platforms, like mobile and desktop, you can select from redirect URIs generated for you when you configure their other settings.

To configure application settings based on the platform or device you're targeting:

1. Select your application in App registrations in the Azure portal.

2. Under Manage, select Authentication.

3. Under Platform configurations, select Add a platform.

4. In Configure platforms, select the tile for your application type (platform) to configure its settings.

   

    

   Platform	Configuration settings
   Web	Enter a Redirect URI for your app, the location where Microsoft identity platform redirects a user's client and sends security tokens after authentication. Select this platform for standard web applications that run on a server.
   Single-page application	Enter a Redirect URI for your app, the location where Microsoft identity platform redirects a user's client and sends security tokens after authentication. Select this platform if you're building a client-side web app in JavaScript or with a framework like Angular, Vue.js, React.js, or Blazor WebAssembly.
   iOS/macOS	Enter the app Bundle ID, found in XCode in Info.plist or Build Settings.A redirect URI is generated for you when you specify a Bundle ID.
   Android	Enter the app Package name, which you can find in the AndroidManifest.xml file, and generate and enter the Signature hash.A redirect URI is generated for you when you specify these settings.
   Mobile and desktop applications	Select one of the Suggested redirect URIs or specify a Custom redirect URI.For desktop applications, we recommend:https://login.microsoftonline.com/common/oauth2/nativeclient Select this platform for mobile applications that aren't using the latest Microsoft Authentication Library (MSAL) or aren't using a broker. Also select this platform for desktop applications.

5. Select Configure to complete the platform configuration.

Add credentials

Credentials are used by confidential client applications that access a web API. Examples of confidential clients include web apps, other web APIs, and service-type and daemon-type applications. Credentials allow your application to authenticate as itself, requiring no interaction from a user at runtime.

You can add both certificates and client secrets (a string) as credentials to your confidential client app registration.

Add a certificate

Sometimes called a public key, certificates are the recommended credential type, because as they provide a higher level of assurance than a client secret. When using a trusted public certificate, you can add the certificate using the Certificates & secrets feature. Your certificate must be one of the following file types: .cer, .pem, .crt.

Add a client secret

The client secret, also known as an application password, is a string value your app can use in place of a certificate to identity itself. It's the easier of the two credential types to use. It's often used during development, but is considered less secure than a certificate. You should use certificates in your applications running in production.

1. Select your application in App registrations in the Azure portal.
2. Select Certificates and secrets, then select New client secret.
3. Add a description for your client secret.
4. Select a duration.
5. Select Add.
6. Record the secret's value for use in your client application code; It's never displayed again after you leave this page.

Register the web API

To provide scoped access to the resources in your web API, you must first register the API with the Microsoft identity platform.

1. Perform the steps above.
2. Skip the Add a redirect URI and Configure platform settings sections. You don't need to configure a redirect URI for a web API since no user is logged in interactively.
3. Skip the Add credentials section for now. Only if your API accesses a downstream API would it need its own credentials—a scenario not covered in this article.

With your web API registered, you're ready to add the scopes that your API's code can use to provide granular permission to consumers of your API.

Add a scope

The code in a client application requests permission to perform operations defined by your web API by passing an access token along with its requests to the protected resource (the web API). Your web API then performs the requested operation only if the access token it receives contains the scopes (also known as application permissions) required for the operation.

First, follow these steps to create an example scope named Employees.Read.All:

1. Sign in to the Azure portal.

2. If you have access to multiple tenants, use the Directory + subscription filter in the top menu to select the tenant containing your client app's registration.

3. Select Microsoft Entra ID, then App registrations, and then select your API's app registration.

4. Select Expose an API, then Add a scope.

   

5. You're prompted to set an Application ID URI if you haven't yet configured one. The App ID URI acts as the prefix for the scopes you'll reference in your API's code, and it must be globally unique. You can use the default value provided, which is in the form api:// , or specify a more readable URI like https://contoso.com/api.

6. Next, specify the scope's attributes in the Add a scope pane. For this walk-through, you can use the example values or specify your own.

    

   Field	Description	Example
   Scope name	The name of your scope. A common scope naming convention is resource.operation.constraint.	Employees.Read.All
   Who can consent	The admin chooses if this scope can be consented to by users, or if admin consent is required. Select Admins only for higher-privileged permissions.	Admins and users
   Admin consent display name	A short description of the scope's purpose that only admins will see.	Read-only access to employee records
   Admin consent description	A more detailed description of the permission granted by the scope that only admins will see.	Allow the application to have read-only access to all employee data.
   User consent display name	A short description of the scope's purpose. Shown to users only if you set the Who can consent to Admins and users.	Read-only access to your employee records
   User consent description	A more detailed description of the permission granted by the scope. Shown to users only if you set the Who can consent to Admins and users.	Allow the application to have read-only access to your employee data.

7. Set the State to Enabled, and then select Add scope.

8. (Optional) To suppress prompting for consent by users of your app to the scopes you've defined, you can pre-authorize the client application to access your web API. Pre-authorize only those client applications you trust since your users won't have the opportunity to decline consent.

   1. Under Authorized client applications, select Add a client application.
   2. Enter the Application (client) ID of the client application you want to pre-authorize. For example, that of a web application you've previously registered.
   3. Under Authorized scopes, select the scopes for which you want to suppress consent prompting, then select Add application.
   4. If you followed this optional step, the client app is now a pre-authorized client app (PCA), and users won't be prompted for their consent when signing into it.

Add a scope requiring admin consent

Next, add another example scope named Employees.Write.All that only admins can consent to. Scopes that require admin consent are typically used for providing access to higher-privileged operations, often by client applications that run as backend services or daemons that don't sign in a user interactively.

To add the Employees.Write.All example scope, follow the steps above and specify these values in the Add a scope pane:

 

Field	Example value
Scope name	Employees.Write.All
Who can consent	Admins only
Admin consent display name	Write access to employee records
Admin consent description	Allow the application to have write access to all employee data.
User consent display name	None (leave empty)
User consent description	None (leave empty)

Verify the exposed scopes

If you successfully added both example scopes described in the previous sections, they'll appear in the Expose an API pane of your web API's app registration, similar to this image:

As shown in the image, a scope's full string is the concatenation of your web API's Application ID URI and the scope's Scope name.

For example, if your web API's application ID URI is https://contoso.com/api and the scope name is Employees.Read.All, the full scope is:

https://contoso.com/api/Employees.Read.All

Using the exposed scopes

Next, you'll configure a client app's registration with access to your web API and the scopes you defined by following the steps above.

Once a client app registration is granted permission to access your web API, the client can be issued an OAuth 2.0 access token by the Microsoft identity platform. When the client calls the web API, it presents an access token whose scope (scp) claim is set to the permissions you've specified in the client's app registration.

You can expose additional scopes later as necessary. Consider that your web API can expose multiple scopes associated with several operations. Your resource can control access to the web API at runtime by evaluating the scope (scp) claim(s) in the OAuth 2.0 access token it receives.

What is going on behind the scenes

• The app registration is created in the home tenant
• The app is instantiated with a security principal in Microsoft Entra ID
• The security principal is granted consent by either the first user or admin, based on the setup of the exposed API
• The security principal is granted the security token as the user accesses the application and uses the API

---

Next unit: Configure permission for an application