Authentication github（twitter、stripe&；co）是否使用oauth进行自己的登录？

github（twitter、stripe&co）是否将OAuth用于自己的登录/注册表单

所有这些身份验证都是基于cookie的，所以这是常规web客户端基本身份验证还是使用某种形式的OAuth或xAuth

登录时，调用（或或）（凭据作为formdata提供），结果是使用

Set Cookie

生成302（或200表示条带），并将位置设置为（或）

他们似乎没有使用

客户机id

来获取

代码

，并将其与

令牌

交换。所有的OAuth舞蹈似乎都有条纹。还有承载头。那么，这是怎么回事

---

谢谢。

OAuth是一个三条腿的系统，两条腿有点没用。使用OAuth的全部意义在于，让其他服务能够根据需要执行操作，而无需自己专门验证或传递数据。最后，您仍然必须针对某个身份验证服务进行身份验证

因为您正在使用这些服务作为其他站点的身份验证机制，所以在您自己的站点中尝试使用它是没有意义的。作为设置OAuth的一部分，第二个站点重定向到第一个站点并要求在那里进行身份验证，这意味着您确实需要输入您的凭据。这意味着，如果您可以将凭据输入到github中，那么使用不同的身份验证机制是没有用的

OAuth允许非github通过信任github进行身份验证来创建用户帐户，或者允许非github站点在用户同意交互后以用户身份对github进行更改，方法是登录github以接受该策略（使用其凭据登录）。

在github（以及其他网站）上登录表单都是基于cookie的

通常，通过浏览器通过网站直接登录都是使用基于cookie的系统进行的，这仅仅是因为不需要这样做

一点理论 每次在网站中使用登录表单时，您都在调用一个API，不一定是供公共使用的（因此是一个私有API）

当您将凭证放入登录表单并按下登录按钮时，您的凭证将由服务器中的某些代码管理，该代码允许您对该网站进行身份验证

这里不需要整个OAuth开销，因为网站可以完全控制身份验证机制，不需要外部化

为什么OAuth在这场比赛中与众不同？ OAuth是一个设计用于跨不同服务/应用程序（甚至来自不同供应商）分发身份验证系统的系统

在OAuth中，涉及多个参与者：

• 客户
• 授权服务器
• 资源提供者

---

在您的情况下，所有这三个参与者都是网站本身，因此不需要像OAuth这样的解耦系统。

检查安全部分完全同意OAuth为其他服务进行身份验证委派。因此，网站身份验证机制（经典登录/通行证）与OAuth没有任何关系？它可能会使用基本身份验证，你不认为吗？看起来github只是使用加密的formdata，然后将结果保存为cookie（可能是最常见的）。由于网站可以保存Cookie，并且我在请求中看到了

Cookie

头，这很可能就是发送数据的方式（不使用auth头，此时auth机制可以是任何东西）。Bearer具体指的是一种特定的身份验证类型，但由于网站可以进行身份验证，因为您实际上是在传递用户名：密码，因此结果必须是会话令牌。我想他们只是在拿回令牌时验证它。