Azure AD - 区分应用令牌和用户令牌
Azure AD - Differentiate between App token and User token
我正在构建一个受 Azure AD Oauth 不记名令牌身份验证保护的 asp.net webapi。我正在使用 Azure AD Bearer 令牌验证 OWIN 中间件来验证令牌并提取声明。
我需要区分请求何时来自服务上下文以及请求何时来自用户上下文。我知道 App 令牌（由 AD 为 APP 上下文颁发）不会有任何我可以轻松识别的 UPN 声明，但我想知道他们是否有任何标准方法来做到这一点？
引用自内部论坛：
The appidacr claim indicates the type of client authentication performed. For a confidential client, the value is 1 when a shared secret (a password) is used as a client secret and 2 when a certificate is used as a client secret. The value 0 indicates a public client, which does not provide a client secret and therefore does not authenticate to the STS. Since confidential clients can acquire both user delegated and app only access tokens, the appidacr claim alone does not help to distinguish a user token from an app-only token.
If you want to distinguish between app-only access tokens, user-delegated access tokens, and id tokens issued by Azure AD (all of which are JWTs signed by the same key), follow this guidance:
- First of all, validate the ver claim's value is 1.0.
- Next, check to see if the JWT is an access token or an id token. The most reliable way to distinguish between the two is the presence of the appid and appidacr claims. These claims will be present in access tokens, but not id tokens.
- If the JWT is an id token, then it represents a user. The subject of an id token issued by Azure AD is always a user. Never accept an id token as proof of authentication, always require an access token.
- If the JWT is an access token, the presence of an scp (scope) claim informs you that the token is a user delegated access token. The value of the scp claim tells you what authorization the client has been granted by the user.
- If the access token does not have an scp claim, it is an app-only access token. In this case, it may have a roles claim.
Don't rely on UPN and email claims to determine the type of token, they're not as reliable.
Your application may receive tokens on behalf of a user (the usual flow) or directly from an application (through the client credentials flow). These app-only tokens indicate that this call is coming from an application and does not have a user backing it. These tokens are handled largely the same, with some differences:
- App-only tokens will not have a scp claim, and may instead have a roles claim. This is where application permission (as opposed to delegated permissions) will be recorded. For more information about delegated and application permissions, see permission and consent in v1.0 and v2.0.
- Many human-specific claims will be missing, such as name or upn.
- The sub and oid claims will be the same.
就我个人而言，在我的代码中，为了确定令牌是否为 App 令牌，我使用了检查声明的组合："oid" 和 "sub" 两者 存在 和 相同，以及检查令牌是否 不 包含名称声明。
在实践中，我发现使用不同流程颁发的令牌可以包含不同的声明，这就是为什么我发现使用其中几个属性的组合可以更好地区分用户和应用程序令牌.
现在有一种受支持的方式来判断令牌是否用于应用程序。
Azure Ad 支持配置访问令牌，让您的受保护资源拥有some optional claims。声明需要回答“Is token for App?”是“idtyp”
请参阅 Configuring optional claims 了解如何设置
我正在构建一个受 Azure AD Oauth 不记名令牌身份验证保护的 asp.net webapi。我正在使用 Azure AD Bearer 令牌验证 OWIN 中间件来验证令牌并提取声明。
我需要区分请求何时来自服务上下文以及请求何时来自用户上下文。我知道 App 令牌（由 AD 为 APP 上下文颁发）不会有任何我可以轻松识别的 UPN 声明，但我想知道他们是否有任何标准方法来做到这一点？
引用自内部论坛：
The appidacr claim indicates the type of client authentication performed. For a confidential client, the value is 1 when a shared secret (a password) is used as a client secret and 2 when a certificate is used as a client secret. The value 0 indicates a public client, which does not provide a client secret and therefore does not authenticate to the STS. Since confidential clients can acquire both user delegated and app only access tokens, the appidacr claim alone does not help to distinguish a user token from an app-only token.
If you want to distinguish between app-only access tokens, user-delegated access tokens, and id tokens issued by Azure AD (all of which are JWTs signed by the same key), follow this guidance:
- First of all, validate the ver claim's value is 1.0.
- Next, check to see if the JWT is an access token or an id token. The most reliable way to distinguish between the two is the presence of the appid and appidacr claims. These claims will be present in access tokens, but not id tokens.
- If the JWT is an id token, then it represents a user. The subject of an id token issued by Azure AD is always a user. Never accept an id token as proof of authentication, always require an access token.
- If the JWT is an access token, the presence of an scp (scope) claim informs you that the token is a user delegated access token. The value of the scp claim tells you what authorization the client has been granted by the user.
- If the access token does not have an scp claim, it is an app-only access token. In this case, it may have a roles claim.
Don't rely on UPN and email claims to determine the type of token, they're not as reliable.
Your application may receive tokens on behalf of a user (the usual flow) or directly from an application (through the client credentials flow). These app-only tokens indicate that this call is coming from an application and does not have a user backing it. These tokens are handled largely the same, with some differences:
- App-only tokens will not have a scp claim, and may instead have a roles claim. This is where application permission (as opposed to delegated permissions) will be recorded. For more information about delegated and application permissions, see permission and consent in v1.0 and v2.0.
- Many human-specific claims will be missing, such as name or upn.
- The sub and oid claims will be the same.
就我个人而言，在我的代码中，为了确定令牌是否为 App 令牌，我使用了检查声明的组合："oid" 和 "sub" 两者 存在 和 相同，以及检查令牌是否 不 包含名称声明。
在实践中，我发现使用不同流程颁发的令牌可以包含不同的声明，这就是为什么我发现使用其中几个属性的组合可以更好地区分用户和应用程序令牌.
现在有一种受支持的方式来判断令牌是否用于应用程序。
Azure Ad 支持配置访问令牌，让您的受保护资源拥有some optional claims。声明需要回答“Is token for App?”是“idtyp”
请参阅 Configuring optional claims 了解如何设置