OAuth授权与认证
OAuth授权与认证
OAuth术语一直困扰着我很长时间了。有些人认为OAuth是授权，还是认证呢？\n如果我有错，请纠正我，但我一直理解授权是允许某人访问资源的行为，然而OAuth似乎没有任何实现实际允许用户访问特定资源的方式。所有的OAuth实现都只是提供给用户一个令牌（有时还会进行签名和加密）。然后，这个令牌会在每个调用后端服务端点的时候传递，并进行有效性检查，这不是OAuth的关注点。\nOAuth是否是认证（每篇文章都说不是），我理解认证需要用户提供凭证，从而证明用户应该/不应该有访问权限？\n因此，OAuth既不是授权也不是认证，因为这些都需要由其他流程执行。那到底OAuth是什么？是用于传递令牌的过程吗？还是一个没有具体含义的虚词？\n关于这个主题提问很难不让人听起来像谜一样神秘（鬼魂和妖怪），所以我预计回答这个问题也不会是一件简单的事情。自行决定是否冒险进入。
OAuth是一种授权协议，不是用于认证的。在OAuth过程中有一步是身份服务器对资源拥有者进行认证，但这不属于OAuth协议的范畴。这就是为什么OAuth不关心认证的原因。
OAuth通过向第三方（服务提供商）提供访问令牌来执行授权，并且该第三方可以通过提供令牌来授权访问资源。
假设有一个需求，服务提供商想代表资源拥有者访问由身份服务器保护的资源。因此，资源拥有者首先进行认证，然后授权服务提供商访问特定资源。然后身份服务器将为服务提供商发放访问令牌。稍后，服务提供商可以使用该令牌访问资源。
在这里，OAuth不关心携带访问令牌的人或试图访问资源的人是谁。它验证访问令牌，并允许第三方访问资源。
OAuth的出现是为了解决授权和认证的问题。它通过将认证和授权分离，使得系统更加安全和灵活。通过将认证交给身份服务器处理，OAuth能够保证只有经过认证的用户才能够获得访问令牌。这样可以防止未经认证的用户访问受保护的资源。
解决方法是使用OAuth协议来进行授权，同时使用其他认证机制来进行身份验证。这样可以保证身份验证和授权的分离，提高系统的安全性和灵活性。
以下是一个使用OAuth进行授权的示例代码：
from oauthlib.oauth2 import BackendApplicationClient
from requests_oauthlib import OAuth2Session
client_id = 'your_client_id'
client_secret = 'your_client_secret'
token_url = 'https://identityserver.com/token'
client = BackendApplicationClient(client_id=client_id)
oauth = OAuth2Session(client=client)
token = oauth.fetch_token(token_url=token_url, client_id=client_id, client_secret=client_secret)
# 使用获得的令牌访问受保护的资源
response = oauth.get('https://resourceserver.com/resource', headers={'Authorization': 'Bearer ' + token['access_token']})
通过上述代码，服务提供商可以使用OAuth协议获取访问令牌，并使用该令牌访问受保护的资源。这样能够保证只有经过认证的用户才能够访问资源，提高系统的安全性。
OAuth Authorization vs Authentication
在讨论OAuth的授权和认证之前，首先需要明确OAuth 2.0是一种授权规范，而不是认证规范。RFC 6749中明确指出，授权服务器首先需要验证资源所有者的身份，但对于如何验证资源所有者的身份并不在该规范的范围内。
然而，由于授权流程中包含了认证的第一步，这使得人们经常混淆授权和认证的概念。因此，许多库和服务都使用OAuth 2.0进行认证，通常被称为“社交登录”，这进一步增加了人们的困惑。
为了解决这个问题，OpenID 1.0和OpenID 2.0被提出作为认证的规范。然而，一些人开始使用OAuth 2.0进行认证，而不是授权，这导致OAuth认证迅速流行起来。面对这种情况，OpenID的开发者不得不承认人们更喜欢OAuth认证，于是他们决定在OAuth 2.0的基础上定义一个新的规范，即OpenID Connect。
OAuth 2.0是一种框架，允许服务的用户在不向第三方应用程序透露自己的凭据（ID和密码）的情况下，允许第三方应用程序访问其托管在该服务中的数据。
OpenID Connect是在OAuth 2.0之上定义的一种框架，允许第三方应用程序获取由服务管理的用户身份信息。
从实现者的角度来看，认证是确定最终用户的主体（唯一标识符）的过程，而授权是将主体与请求的权限和请求权限的客户端应用程序关联起来的过程。访问令牌表示此关联。
总之，OAuth授权和认证的概念经常被混淆，但它们实际上是不同的概念。为了解决这个问题，OpenID Connect规范被提出，并在OAuth 2.0的基础上定义了一种新的框架，以满足人们对于认证和授权的需求。
参考链接：
- [RFC 6749](https://www.rfc-editor.org/rfc/rfc6749)
- [OpenID Connect](http://openid.net/connect/)
- [OAuth 2.0和OpenID Connect实现者的发现](https://medium.com/full-scratch-implementor-of-oauth-and-openid-connect-talks-about-findings-55015f36d1c3)
- [OAuth 2.0流程的图表和动画](https://medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85)
- [OpenID Connect流程的图表](https://medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660)
- [OAuth 2.0最简单指南](https://medium.com/the-simplest-guide-to-oauth-2-0-8c71bd9a15bb)