OpenID 连接用例
OpenID Connect use case
最近我发现了 OpenID Connect 标准，现在我正在努力寻找正确的使用方法。
假设我正在构建一个非常标准的 Web 应用程序，它必须具有经过身份验证的用户的概念。所以我的第一个意图是用用户 table 构建一个本地数据库，包含用户 ID、电子邮件、名字和姓氏、密码、salt 等。
这意味着我需要实现所有相关功能，例如注册、登录、change/forget 密码等
我没有这样做，而是选择使用 OpenID 连接并利用存储在其他地方（例如 Google）的用户信息。
然后我可以执行通常的 OAuth2 魔法来重定向用户、征求同意等。
从这一点开始，我有点迷失方向了。在 Google（或任何 AS）返回到我的后端应用程序 ID 令牌和基本用户信息（电子邮件、姓名、phone）之后
我该怎么办？我还应该有一个本地用户数据库（没有密码）从这些字段中填充吗？在这种情况下，OpenID Connect 只是一个花哨的自动注册程序？关于会话和注销，如果用户在 Google 站点上更改了他的 phone，而我仍然保存旧版本，该怎么办？
我在网上阅读了很多 OpenID Connect 文章，但它们似乎都描述了获取令牌的基本流程，所以我对进一步的阶段感到困惑。
我非常感谢关于这个问题的任何提示/建议。
我同意你的看法，这些现代身份验证方案最有趣的方面是你可以轻松地将身份验证委托给第三方提供商，而不必编写和支持所有样板代码，而是高度敏感的代码围绕管理用户身份。
关于你，接下来会发生什么问题让我们一一探讨；我会尽量不以它来开始每个答案。
Q1我是否仍然可以使用这些字段填充本地用户数据库（无密码）？
这取决于，如果您的应用程序不需要在用户不在线与应用程序交互时了解用户信息，那么您几乎不需要存储任何东西就可以逃脱。您至多想为用户创建的数据存储一个唯一的用户标识符。
另一方面，如果您的应用程序在（真正）有趣的事情发生时通过电子邮件通知用户，那么您需要将用户电子邮件存储在您的数据库中。
Q2（如果我需要复制我数据库中几乎所有的信息是）OpenID Connect只是一个喜欢自动注册程序吗？
某种程度上，作为一种允许您将应用程序身份验证委托给第三方的标准，您已经从它的存在中获得了巨大的好处。身份验证不是微不足道的，如果您可以将其卸载给其他人，那就去做吧。通过这样做，您也帮了最终用户一个忙，因为（取决于您选择的提供商的受欢迎程度）他现在可以登录到您的应用程序，而无需记住另一组凭据。
Q3会话和注销怎么办？
如果你想要一个独立的会话，这里没有实质性的变化。在您的应用程序验证凭据并启动会话之前，现在它将验证可能由第三方提供的令牌，然后启动会话。注销只会结束您的会话。
如果您想要同步会话，以便用户仅在您的应用程序中处于活动状态，同时他在第三方提供商中也有一个会话，那么您需要做更多的工作。看看，如果您还没有这样做，OpenID Connect Session Management 1.0 了解更多信息。
Q4如果用户在 Google 网站上更改他的 phone 会怎样我还有它保存的旧版本？
这不是问题，因为如果您不使用 OpenID Connect 并且必须管理特定于应用程序的用户身份，您也会遇到同样的问题。用户会在 Google 上更改他们的 phone，除非他也主动更改您应用中的 phone，否则它会过时。
正如 fiddur 指出的那样，如果有更新的信息，也可以主动与提供商核实。这是大多数供应商都支持的东西，并且有附带的好处，也可以为最终用户提供良好的用户体验。
总而言之，如果您有机会将身份验证委托给外部提供商，请这样做。实施您自己的自定义身份验证，甚至将您自己建立为符合所有可用标准的身份验证提供者，都是一项非常耗时的挑战，充满安全隐患。
如果您认为您需要比社交身份验证提供商更好地控制身份验证过程，仍然可以选择更灵活的提供商，Auth0 想到了，但我有偏见 ( 我是 Auth0 工程师 )。这种类型的选项会给你更多的控制权，同时仍然背负着实施身份验证标准的负担。
最近我发现了 OpenID Connect 标准，现在我正在努力寻找正确的使用方法。
假设我正在构建一个非常标准的 Web 应用程序，它必须具有经过身份验证的用户的概念。所以我的第一个意图是用用户 table 构建一个本地数据库，包含用户 ID、电子邮件、名字和姓氏、密码、salt 等。 这意味着我需要实现所有相关功能，例如注册、登录、change/forget 密码等
我没有这样做，而是选择使用 OpenID 连接并利用存储在其他地方（例如 Google）的用户信息。
然后我可以执行通常的 OAuth2 魔法来重定向用户、征求同意等。
从这一点开始，我有点迷失方向了。在 Google（或任何 AS）返回到我的后端应用程序 ID 令牌和基本用户信息（电子邮件、姓名、phone）之后 我该怎么办？我还应该有一个本地用户数据库（没有密码）从这些字段中填充吗？在这种情况下，OpenID Connect 只是一个花哨的自动注册程序？关于会话和注销，如果用户在 Google 站点上更改了他的 phone，而我仍然保存旧版本，该怎么办？
我在网上阅读了很多 OpenID Connect 文章，但它们似乎都描述了获取令牌的基本流程，所以我对进一步的阶段感到困惑。
我非常感谢关于这个问题的任何提示/建议。
我同意你的看法，这些现代身份验证方案最有趣的方面是你可以轻松地将身份验证委托给第三方提供商，而不必编写和支持所有样板代码，而是高度敏感的代码围绕管理用户身份。
关于你，接下来会发生什么问题让我们一一探讨；我会尽量不以它来开始每个答案。
Q1我是否仍然可以使用这些字段填充本地用户数据库（无密码）？
这取决于，如果您的应用程序不需要在用户不在线与应用程序交互时了解用户信息，那么您几乎不需要存储任何东西就可以逃脱。您至多想为用户创建的数据存储一个唯一的用户标识符。
另一方面，如果您的应用程序在（真正）有趣的事情发生时通过电子邮件通知用户，那么您需要将用户电子邮件存储在您的数据库中。
Q2（如果我需要复制我数据库中几乎所有的信息是）OpenID Connect只是一个喜欢自动注册程序吗？
某种程度上，作为一种允许您将应用程序身份验证委托给第三方的标准，您已经从它的存在中获得了巨大的好处。身份验证不是微不足道的，如果您可以将其卸载给其他人，那就去做吧。通过这样做，您也帮了最终用户一个忙，因为（取决于您选择的提供商的受欢迎程度）他现在可以登录到您的应用程序，而无需记住另一组凭据。
Q3会话和注销怎么办？
如果你想要一个独立的会话，这里没有实质性的变化。在您的应用程序验证凭据并启动会话之前，现在它将验证可能由第三方提供的令牌，然后启动会话。注销只会结束您的会话。
如果您想要同步会话，以便用户仅在您的应用程序中处于活动状态，同时他在第三方提供商中也有一个会话，那么您需要做更多的工作。看看，如果您还没有这样做，OpenID Connect Session Management 1.0 了解更多信息。
Q4如果用户在 Google 网站上更改他的 phone 会怎样我还有它保存的旧版本？
这不是问题，因为如果您不使用 OpenID Connect 并且必须管理特定于应用程序的用户身份，您也会遇到同样的问题。用户会在 Google 上更改他们的 phone，除非他也主动更改您应用中的 phone，否则它会过时。
正如 fiddur 指出的那样，如果有更新的信息，也可以主动与提供商核实。这是大多数供应商都支持的东西，并且有附带的好处，也可以为最终用户提供良好的用户体验。
总而言之，如果您有机会将身份验证委托给外部提供商，请这样做。实施您自己的自定义身份验证，甚至将您自己建立为符合所有可用标准的身份验证提供者，都是一项非常耗时的挑战，充满安全隐患。
如果您认为您需要比社交身份验证提供商更好地控制身份验证过程，仍然可以选择更灵活的提供商，Auth0 想到了，但我有偏见 ( 我是 Auth0 工程师 )。这种类型的选项会给你更多的控制权，同时仍然背负着实施身份验证标准的负担。