[Microsoft identity platform]令牌和声明概述

A centralized identity provider is especially useful for apps that have worldwide users who don't necessarily sign in from the enterprise's network. The Microsoft identity platform authenticates users and provides security tokens, such as access tokens, refresh tokens, and ID tokens. Security tokens allow a client application to access protected resources on a resource server.

• 访问令牌-访问令牌是由授权服务器作为OAuth 2.0流的一部分颁发的安全令牌。它包含有关用户和令牌所针对的资源的信息。这些信息可用于访问web API和其他受保护的资源。资源验证访问令牌以授予对客户端应用程序的访问权限。有关详细信息，请参阅Microsoft身份平台中的访问令牌。
• 刷新令牌-由于访问令牌的有效期很短，授权服务器有时会在颁发访问令牌的同时颁发刷新令牌。然后，客户端应用程序可以在需要时将此刷新令牌交换为新的访问令牌。有关详细信息，请参阅Microsoft身份平台中的刷新令牌。
• ID令牌-ID令牌作为OpenID Connect流的一部分发送到客户端应用程序。它们可以与访问令牌一起发送，也可以代替访问令牌发送。ID令牌由客户端用于对用户进行身份验证。要了解有关Microsoft身份平台如何颁发ID令牌的更多信息，请参阅Microsoft身份平台中的ID令牌。

Many enterprise applications use SAML to authenticate users. For information on SAML assertions, see SAML token reference.

It's up to the application for which the token was generated, the web app that signed in the user, or the web API being called to validate the token. The authorization server signs the token with a private key. The authorization server publishes the corresponding public key. To validate a token, the app verifies the signature by using the authorization server public key to validate that the signature was created using the private key. For more information, check out the Secure applications and APIs by validating claims article.

We recommend you use the supported Microsoft Authentication Libraries (MSAL) whenever possible. This implements the acquisition, refresh, and validation of tokens for you. It also implements standards-compliant discovery of tenant settings and keys using the tenant’s OpenID well-known discovery document. MSAL supports many different application architectures and platforms including .NET, JavaScript, Java, Python, Android, and iOS.

Tokens are valid for only a limited amount of time, so the authorization server frequently provides a pair of tokens. An access token is provided, which accesses the application or protected resource. A refresh token is provided, which is used to refresh the access token when the access token is close to expiring.

Access tokens are passed to a web API as the bearer token in the Authorization header. An app can provide a refresh token to the authorization server. If the user access to the app wasn't revoked, it receives a new access token and a new refresh token. When the authorization server receives the refresh token, it issues another access token only if the user is still authorized.

Microsoft身份平台将安全令牌实现为包含声明的JSON Web令牌（JWT）。由于JWT被用作安全令牌，这种形式的身份验证有时被称为JWT身份验证。

声明向另一实体（如资源服务器）提供关于一个实体（如客户端应用程序或资源所有者）的断言。声明也可以称为JWT声明或JSON Web令牌声明。

声明是传递有关令牌主题的事实的名称或值对。例如，声明可能包含有关授权服务器验证的安全主体的事实。特定令牌中的声明取决于许多因素，例如令牌的类型、用于验证主体的凭证类型以及应用程序配置。

应用程序可以将声明用于以下各种任务：

• 验证令牌
• 识别令牌主体的租户
• 显示用户信息
• 确定受试者的授权

声明由提供以下类型信息的键值对组成：

• 生成令牌的安全令牌服务器
• 生成令牌的日期
• 主题（类似于用户，但不是守护进程）
• Audience，即生成令牌的应用程序
• 请求令牌的应用程序（客户端）

Microsoft Entra ID supports two tenant configurations: A workforce configuration that’s intended for internal use and manages employees and business guests, and a customer configuration which is optimized for isolating consumers and partners in a restricted external-facing directory. While the underlying identity service is identical for both tenant configurations, the login domains and token issuing authority for external tenants is different. This allows applications to keep workforce and external ID workflows separated if needed.

Microsoft Entra workforce tenants authenticate at login.microsoftonline.com with tokens issued by sts.windows.net. Workforce tenant tokens are generally interchangeable across tenants and multi-tenant applications so long as underlying trust relationships permit this interoperability. Microsoft Entra external tenants use tenanted endpoints of the form {tenantname}.ciamlogin.com. Applications registered to external tenants must be aware of this separation to receive and validate tokens correctly.

Every Microsoft Entra tenant publishes a standards-compliant well-known metadata. This document contains information about the issuer name, the authentication and authorization endpoints, supported scopes and claims. For external tenants, the document is publicly available at: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. This endpoint returns an issuer value https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.

Depending on how your client is built, it can use one or several of the authentication flows supported by the Microsoft identity platform. The supported flows can produce various tokens and authorization codes and require different tokens to make them work. The following table provides an overview.

Tokens issued using the implicit flow have a length limitation because they're passed back to the browser using the URL, where response_mode is query or fragment. Some browsers have a limit on the size of the URL that can be put in the browser bar and fail when it's too long. As a result, these tokens don't have groups or wids claims.

• OAuth 2.0
• OpenID Connect

• To learn about the basic concepts of authentication and authorization, see Authentication vs. authorization.