验证Azure广告访问令牌时签名无效 [英] Invalid signature while validating Azure ad access token

问题描述

使用jwt.io验证我的azure广告访问令牌时，我得到了无效签名(手动检查后将转换为scala代码).

I am getting invalid signature while using jwt.io to validate my azure ad access token (will shift to scala code after the manual checking).

我正在使用curl生成访问令牌:

I am using curl to generate the access token:

curl -s -X POST https://login.microsoftonline.com/<tenant id>/oauth2/token -d grant_type=password -d username=$username -d password=$pass  -d resource=$resID -d client_id=$id -d client_secret=$key

虽然给我访问令牌，但响应中不包含"Id_token".不知道为什么.

While it is giving me the access token, the response doesnt contain the "Id_token". Not sure why.

我从 https://login.microsoftonline.com/common/包装了公钥带有BEGIN和END证书的发现/密钥. (如 https:中所述://nicksnettravels.builttoroam.com/post/2017/01/24/Verifying-Azure-Active-Directory-JWT-Tokens.aspx )

我不确定还缺少什么.

解码后的标头如下:

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "9FXDpbfMFT2SvQuXh846YTwEIBw",
  "kid": "9FXDpbfMFT2SvQuXh846YTwEIBw"
}

推荐答案

警告:您正在调用不受支持的流，并将在不久的将来将其删除.

在具有机密客户端(即存在client_secret的web应用程序/web API)的Azure AD中，不支持资源所有者密码凭据授予流(grant_type=password).如果您确信您的方案需要资源所有者流程(很少有方案实际承担此流程所带来的风险)，那么您应该使用为本机客户端应用程序(公共客户端)注册的client_id来调用它.另外，您应该调用一个交互式登录(如果您是实际的人工用户登录)，或追求客户端证书授予"流程(如果这是一个守护程序/无人值守服务).

The Resource Owner Password Credentials Grant flow (grant_type=password) is not supported in Azure AD with confidential clients (i.e. web app/web API, where there exists a client_secret). If you are confident your scenario requires the Resource Owner flow (very few scenarios actually warrant the risks introduced by this flow), then you should be invoking it with a client_id registered for a native client app (a public client). Alternatively, you should be invoking an interactive sign-in (if you are signing in actual human users), or pursuing the Client Credentials Grant flow (if this is a daemon/unattended service).

您没有获得ID令牌，因为您调用的流程(OAuth 2.0资源所有者密码凭据授予流程)没有定义ID令牌或id_token响应的任何概念.换句话说:您还没有要求.

You are not getting an ID Token because the flow you've invoked (the OAuth 2.0 Resource Owner Password Credentials Grant flow), does not define any concept of an ID Token, or an id_token response. In other words: you haven't asked for one.

如果在授权请求中添加scope=openid，则将向Azure AD暗示您或多或少对了解有关登录人员的知识感兴趣，并且您将获得未签名的OpenID Connect ID响应中的令牌.

If you add scope=openid to your Authorization Request, you'll be hinting to Azure AD that you're more or less interested in knowing stuff about the person who signed in, and you'll get an unsigned OpenID Connect ID Token in the response.

要 https://jwt.io 来验证声明:

1. 确保这是给您的令牌. (即，不希望能够解码和验证不适合您使用的令牌(其中您"是授权请求中的resource和令牌声明中的aud).
2. 确保您选择了正确的签名算法(RS256).
3. 确保您正在检查用于签名令牌的密钥(使用JWT中的kid标头值作为提示).
4. 确保证书以-----END CERTIFICATE-----结尾(我发现jwt.io不太在乎它的开始方式.
5. 仔细检查您的复制粘贴，很容易意外拾取多余的字符.

1. Ensure this is a token intended for you. (i.e. don't expect to be able to decode and verify a token that was not intended for you (where "you" are the resource in the Authorization Request, and the aud in the token claims).
2. Ensure you've selected the correct signing algorithm (RS256).
3. Ensure you're checking against the key with which the token was signed (use the kid header value from the JWT as a hint).
4. Ensure the certificate ends in -----END CERTIFICATE----- (I've found jwt.io doesn't care too much about how it starts.
5. Double-check your copy-pasting, it's easy to accidentally pick up extra characters.

这篇关于验证Azure广告访问令牌时签名无效的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！