我们有一个web应用程序，它使用openid connect和azure作为identityprovider来登录用户。因此，用户在登录时会发送到以下网址：
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?response_type=id_token+token&client_id=3{clientId}&response_mode=form_post&redirect_uri=http://localhost:8765/ms/oidc/signon/response&scope=openid+profile+https://graph.microsoft.com/user.read&state=1234&nonce={nonce}
这很好用，但要求用户在第一次使用时同意我们的应用权限范围。
我们希望Office365管理员能够代表整个租户同意，因此我们会将其发送到以下端点：
https://login.microsoftonline.com/common/adminconsent?client_id={clientId}&state=12345&redirect_uri=http://localhost:8765
这也似乎工作正常，管理员我告知他们将代表其租户中的所有用户同意。但是，首次登录时仍会向用户显示同意提示。 这确实有意义，因为应用程序仅使用user.read权限注册，因此如果我们将用户发送到
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?response_type=token&client_id={clientId}&response_mode=form_post&redirect_uri=http://localhost:8765/ms/oidc/signon/response&scope=https://graph.microsoft.com/user.read&state={state}&nonce={nonce}
如果没有动态权限请求，并且响应类型仅设置为令牌，则管理员同意有效，并且不会向用户显示同意提示。 所以，我想我有两个问题：
1）这是它应该如何工作，还是有某种方式授予管理员同意配置文件和openid范围？
2）我是否因为没有请求这些（openid +个人资料）权限而遗漏了任何内容？我在响应中没有收到并且id_token，但似乎authentication_token已经包含了比id_token更多的信息
答案 0 :(得分：1)
1）这是它应该如何工作，还是有某种方式授予管理员同意配置文件和openid范围？
这似乎是azure ad v2.0同意框架中的一个错误，当您执行管理员权限时，默认情况下应该授予众所周知的范围（openid，profile）。请参阅this link。
2）我是否因为没有请求这些（openid +个人资料）权限而遗漏了任何内容？我在响应中没有收到并且id_token，但似乎authentication_token已经包含了比id_token更多的信息
您没有使用OpenID连接，因为您还没有添加openid范围，因此不会返回id_token。但由于您拥有microsoft graph api的user.read权限，因此您可以使用microsoft graph api来读取用户的基本信息。 Id_token和访问令牌不同，id_token用于标识经过身份验证的用户。 access_token用于证明对受保护资源的访问权限。请点击here了解详情。