使用login.microsoft.com的OAuth返回不一致的令牌 [英] OAuth using login.microsoft.com returns inconsistent tokens

问题描述

我正在使用 office-js-helpers 身份验证库.使用 Microsft Azure AD 2.0 Converged auth 终结点，我测试了来自AD用户(属于AD租户)和 ... @ gmail.com 帐户的登录在Microsoft注册.

I'm using office-js-helpers Authentication library. Using the Microsft Azure AD 2.0 Converged auth endpoint, I have tested logins from both a AD user (belonging to an AD tenant) and a [e-mail] account registered with Microsoft.

它们都返回相似的有效负载，并带有 access_token 属性.主要区别在于，对于AD用户， access_token 是签名的JWT，而对于非AD帐户，访问令牌是base64编码(并且可能是加密/编码)的字符串.

They both return a similar payload, with an access_token property. The major difference is that for the AD user the access_token is a signed JWT, whereas for the non AD account the access token is a base64 encoded (and possibly encrypted/encoded) string.

我可以将任一令牌用于其他Microsoft API(例如Graph API)，因此我没有指出错误.但是我希望将 access_token 用作我自己的API的JWT.

I can use either token for other Microsoft APIs like the Graph API, so I'm not pointing out an error. However I was hoping to use the access_token as a JWT for my own API.

有人处理过这个问题并提出了明智的解决方法吗?

Has anyone dealt with this and come up with a sensible workaround?

推荐答案

尽管MSA帐户未返回基于JWT的 access_token ，但是您可以请求基于JWT的 OpenID Connect .

While MSA accounts don't return a JWT based access_token, you can request a JWT based id_token using OpenID Connect.

考虑OpenID流程的最简单方法是对OAuth 2.0授权代码授予的一种变体.它使用相同的通用模型并带有一些其他参数.

The simplest way to think of the OpenID flow is as a variation on the OAuth 2.0 Authorization Code grant. It uses the same general model with a few additional parameters.

进行初始提供者调用时:

When making the initial provider call:

1. 将 id_token 添加到您的 response_type 查询参数中.

1. Add id_token to your response_type query parameter.

将 openid ， email 和 profile 添加到 scope 查询参数

最终结果应如下所示:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id={ID}&response_type=id_token+code&
redirect_uri={URI}&scope=openid+email+profile+offline_access+user.read

然后，通过授权码"授权即可完成与当前相同的工作流程.但是，最后一步现在将在JSON有效负载中包含一个附加的 id_token 属性:

You then complete the same workflow you're using today with the Authorization Code grant. The final step, however, will now include an additional id_token property in the JSON payload:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

此 id_token 也是基于JWT的令牌，可以像从AAD回来的JWT access_token 一样轻松地进行解码.

This id_token will also be a JWT based token and can be easily decoded just like you're doing with the JWT access_token you're getting back from AAD.

这篇关于使用login.microsoft.com的OAuth返回不一致的令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！