1.对于没有第三方的注册/登录，正如Kevin指出的，每个编程/Web框架通常都带有一个流行的库，一旦它将为您生成所有的注册/登录页面，数据库表，流等。然后您唯一要做的就是调用库提供的方法，该方法返回当前登录的用户，当您需要弄清楚用户是谁时，在后端代码中。
1.使用salted password scheme与OAuth 2.0没有任何关系，正如您所指出的，它是一种广泛使用的本地身份验证方案，因为它有许多好处，但我在这里只强调两个：
a.当通过互联网从用户向服务器传输用于认证的密码时，密码不是以明文发送，而是以散列格式发送。因此，即使被窃听，密码也不会泄露。
B.由于每个密码都被加盐，因此即使2个相同的密码也不会具有相同的哈希，因为每个密码具有不同的盐。因此，即使密码哈希被窃听，它也不能在用户使用相同密码的另一个服务处重用，因为另一个服务期望用不同的盐生成的密码哈希。

1. OAuth2是关于授权的（要求用户允许在另一个Web服务上代表她执行某些操作，例如，要求用户允许访问她在Facebook上注册的电子邮件地址）。OAuth2的最终结果是与许可相关联的访问密钥，例如，'访问电子邮件地址的权限'。当您使用OAuth2结果时（访问密钥）进行身份验证，这意味着你在假设“访问电子邮件地址的权限”意味着用户成功地与Facebook进行了身份验证，她确实做到了，所以看起来没问题。然而，想象一下，如果另一个站点也像您一样使用OAuth2进行身份验证;如果它收到一个带有“访问电子邮件地址的权限”的访问密钥，它将假设您已经通过Facebook的身份验证，因此它将授予您访问属于该电子邮件地址的帐户的权限。您实际上可以使用从用户那里获得的访问密钥，并以她的身份登录其他网站，反之亦然。
   要使用OAuth2进行身份验证，您需要将其与OpenID Connect（OIDC）一起使用，因为OAuth2-OIDC的最终结果包含一个id_token，该id_token带有aud（audience）字段，用于标识访问密钥的对象（https：//openid.net/specs/openid-connect-core-1_0.html#IDToken），这可以防止访问密钥在不需要的地方被重复使用。完整的解释和易于理解的图表如下：https://www.slideshare.net/KhorSoonHin/the-many-flavors-of-oauth/36?src=clipshare
   使用OAuth2登录的另一种非常简单但可能令人不安的安全意识方式是使用资源所有者密码凭据，您的网站充当用户和OAuth2提供商（Facebook）之间的中间人。
   1.显示“使用Facebook登录”按钮
   1.当用户点击按钮时，提示用户输入Facebook用户名/密码
   1.使用用户名/密码登录Facebook以确认身份验证并获取访问令牌。
   如果您没有时间深入阅读有关OAuth2的内容，那么对所有OAuth2流程的并排比较可能会有所帮助。

这是由https://blog.oauth.io/introduction-oauth2-flow-diagrams/提供的

1.您可以像这样使用OAuth进行本地登录，但您不必这样做。根据可用的库，它可能会更容易，并且如果您希望将来将您的服务提供给第三方，它可能是有意义的。但是，对于许多网站来说，使用OAuth进行本地登录可能会矫枉过正。
1.当不同的参与者需要说一种共同的语言以便他们可以互操作时，标准是最有用的。对于本地登录，你不需要标准，因为你不与任何第三方交互。许多Web框架在相同的基本流程上包含自己的变体。
1.我想你是在问，当你实际上并不需要任何授权（访问第三方资源的权限）时，OAuth对于 * 身份验证 *（建立身份）是否有意义。它确实可以这样使用，但很多人会警告它，因为它不是为这一目的而设计的，并且在这种情况下有一些安全漏洞。例如，请参阅使用OAuth进行身份验证的常见陷阱。