为什么 AAD 颁发的访问令牌包含有关用户的信息？
Why do access tokens issued by AAD contain information about the user?
我阅读了很多关于 OAuth 2.0 和 OpenId Connect 的文章，理论上我现在理解了这两个概念。
但是如果我去实践的话，有些事情还是让我很困惑，希望你能以某种方式开导我...
首先，在所有代码示例中如何在 AAD 环境中保护 .net 核心 API 我在配置部分找到了这样的行：
app.UseAuthentication()
ConfigureServices 部分中的类似行：
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
});
但是，要访问我的 API，我没有使用 ID 令牌，而是使用访问令牌什么是 Authorization，而不是“Authentication" 就像在代码示例中一样。
这有效 - 但我不是 100% 理解它。
所以我的第一个问题是：
- 访问令牌在某种程度上也是"authenticating"吗？
第二件事：
我读到访问令牌没有标准化格式。它们可以是也可以不是 JWT，可以有或没有观众等。因此，您甚至可以像微软那样将用户信息放入令牌中。访问令牌包含 "family name" 或 "given name" 等声明
相反，Id 令牌具有标准化格式，以确保每个人都以相同的方式完成身份验证。
如果人们使用访问令牌访问我的 api，我可以使用 "user.identity.name" 读取他们的姓名或电子邮件地址。这个值我可以用来存储信息 who edited something or who inserted something.
所以我正在使用访问令牌获取有关用户的信息！
所以我的第二个问题是：
- 我做的对吗？或者应该以其他方式完成。
和：
- 访问令牌是否应该包含有关用户的信息？
Is the access token also "authenticating" in some way?
是的。
您的 API 在收到访问令牌时正在验证它。
这是身份验证部分，当您的 API 验证令牌签名有效时，来自您信任的 Azure AD 租户，它适用于您的 API 并且尚未过期。
授权就是检查token包含哪些权限。
您的 API 可以定义授予客户端应用程序的不同权限，从而允许它们进行不同级别的访问。
一个有效的token可以通过认证，但是如果缺少必要的权限，它可能无法通过授权。
Am I doing the right thing here? Or should this be done in another way.
从根本上说，您的做法是正确的。
令牌告诉您谁是使用客户端应用程序的用户，如果您需要知道是谁做了某事，那就是您使用的信息。
但是，如果你真的想将一个动作连接到一个用户，我建议你使用他们的对象标识符/对象 ID / oid 而不是他们的名字/用户名，因为它们可以改变。
除非你只是想要他们的显示名称。
Should access tokens ever contain information about the user?
在 Azure AD 的上下文中，如果客户端应用程序代表用户访问 API，访问令牌将始终包含有关用户的信息。
这包括身份验证流程，如授权代码、设备代码、隐式和代表。
他们都使用委托权限 aka 范围来代表用户调用 APIs。
因此令牌包含有关调用应用程序和用户的信息。
如果应用程序使用不涉及用户的客户端凭据流获取访问令牌，则令牌中将没有用户信息。
在这种情况下，使用应用程序权限而不是 Azure AD 中的委派权限。
应用程序作为它自己，不代表任何用户。
如果您的 API 支持这两种情况，则令牌有时包含用户信息，有时不包含。
从规范的角度来看，关于令牌格式的部分基本上是正确的。
OAuth 没有为访问令牌定义严格的格式，而 OpenID Connect 确实为 ID 令牌定义了一种格式。
使用访问令牌调用您的 API 绝对正确。
ID 令牌仅适用于启动用户身份验证的应用程序，不适用于它调用的任何 APIs。
这就是访问令牌的用途。
如果您在此处查看：https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens
在较新的访问令牌中，默认情况下它遵循没有关于用户的任何个人信息的标准。这就是标准所建议的，访问令牌不应包含太多或任何关于用户的信息。而不仅仅是授权信息（用户可以访问的东西）。
但是，您始终可以为个人信息添加可选声明（Azure 允许您这样做），但最佳实践建议您不应该这样做。
就添加身份验证而言：身份验证基本上就是证明您所说的身份。 addauthentication()，基本上调用 microsoft azure ad 来执行此任务，说嘿 aad 请问这个人他是谁，azure 然后检查并说这是一个真实的人，但除了一个id，他们可以访问您的 api/application。所以从你的片段来看，没关系。
在这一点上，您的服务器端不应该有关于用户的任何个人信息，只是他们有访问权限和什么scopes/roles。如果它想要有关用户的信息，那么它应该获取该授权（访问令牌）并从该令牌有权访问的任何端点请求它（图表）
这里有一篇很棒的读物：https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/
希望这有助于澄清一些问题，而不是给问题增加更多的混乱。
我阅读了很多关于 OAuth 2.0 和 OpenId Connect 的文章，理论上我现在理解了这两个概念。
但是如果我去实践的话，有些事情还是让我很困惑，希望你能以某种方式开导我...
首先，在所有代码示例中如何在 AAD 环境中保护 .net 核心 API 我在配置部分找到了这样的行：
app.UseAuthentication()
ConfigureServices 部分中的类似行：
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
});
但是，要访问我的 API，我没有使用 ID 令牌，而是使用访问令牌什么是 Authorization，而不是“Authentication" 就像在代码示例中一样。
这有效 - 但我不是 100% 理解它。
所以我的第一个问题是：
- 访问令牌在某种程度上也是"authenticating"吗？
第二件事：
我读到访问令牌没有标准化格式。它们可以是也可以不是 JWT，可以有或没有观众等。因此，您甚至可以像微软那样将用户信息放入令牌中。访问令牌包含 "family name" 或 "given name" 等声明
相反，Id 令牌具有标准化格式，以确保每个人都以相同的方式完成身份验证。
如果人们使用访问令牌访问我的 api，我可以使用 "user.identity.name" 读取他们的姓名或电子邮件地址。这个值我可以用来存储信息 who edited something or who inserted something.
所以我正在使用访问令牌获取有关用户的信息！
所以我的第二个问题是：
- 我做的对吗？或者应该以其他方式完成。
和：
- 访问令牌是否应该包含有关用户的信息？
Is the access token also "authenticating" in some way?
是的。 您的 API 在收到访问令牌时正在验证它。 这是身份验证部分，当您的 API 验证令牌签名有效时，来自您信任的 Azure AD 租户，它适用于您的 API 并且尚未过期。
授权就是检查token包含哪些权限。 您的 API 可以定义授予客户端应用程序的不同权限，从而允许它们进行不同级别的访问。 一个有效的token可以通过认证，但是如果缺少必要的权限，它可能无法通过授权。
Am I doing the right thing here? Or should this be done in another way.
从根本上说，您的做法是正确的。 令牌告诉您谁是使用客户端应用程序的用户，如果您需要知道是谁做了某事，那就是您使用的信息。 但是，如果你真的想将一个动作连接到一个用户，我建议你使用他们的对象标识符/对象 ID / oid 而不是他们的名字/用户名，因为它们可以改变。 除非你只是想要他们的显示名称。
Should access tokens ever contain information about the user?
在 Azure AD 的上下文中，如果客户端应用程序代表用户访问 API，访问令牌将始终包含有关用户的信息。 这包括身份验证流程，如授权代码、设备代码、隐式和代表。 他们都使用委托权限 aka 范围来代表用户调用 APIs。 因此令牌包含有关调用应用程序和用户的信息。
如果应用程序使用不涉及用户的客户端凭据流获取访问令牌，则令牌中将没有用户信息。 在这种情况下，使用应用程序权限而不是 Azure AD 中的委派权限。 应用程序作为它自己，不代表任何用户。
如果您的 API 支持这两种情况，则令牌有时包含用户信息，有时不包含。
从规范的角度来看，关于令牌格式的部分基本上是正确的。 OAuth 没有为访问令牌定义严格的格式，而 OpenID Connect 确实为 ID 令牌定义了一种格式。
使用访问令牌调用您的 API 绝对正确。 ID 令牌仅适用于启动用户身份验证的应用程序，不适用于它调用的任何 APIs。 这就是访问令牌的用途。
如果您在此处查看：https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens 在较新的访问令牌中，默认情况下它遵循没有关于用户的任何个人信息的标准。这就是标准所建议的，访问令牌不应包含太多或任何关于用户的信息。而不仅仅是授权信息（用户可以访问的东西）。 但是，您始终可以为个人信息添加可选声明（Azure 允许您这样做），但最佳实践建议您不应该这样做。
就添加身份验证而言：身份验证基本上就是证明您所说的身份。 addauthentication()，基本上调用 microsoft azure ad 来执行此任务，说嘿 aad 请问这个人他是谁，azure 然后检查并说这是一个真实的人，但除了一个id，他们可以访问您的 api/application。所以从你的片段来看，没关系。
在这一点上，您的服务器端不应该有关于用户的任何个人信息，只是他们有访问权限和什么scopes/roles。如果它想要有关用户的信息，那么它应该获取该授权（访问令牌）并从该令牌有权访问的任何端点请求它（图表）
这里有一篇很棒的读物：https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/
希望这有助于澄清一些问题，而不是给问题增加更多的混乱。