我如何使用Django的OAuth工具包与Python社会authentication?

我正在使用Django Rest Framework构build一个API。 后来这个API应该被iOS和Android设备使用。 我想让我的用户与Facebook和Google等oauth2提供商签约。 在这种情况下,他们根本不需要在我的平台上创build帐户。 但是用户也应该可以在没有Facebook / Google帐户的情况下注册,因为我使用的是django-oauth-toolkit,所以我有自己的oauth2-provider。

对于外部提供者,我使用python-social-auth,它工作正常并自动创build用户对象。

我希望客户端通过使用持有者令牌进行身份validation,对于与我的提供者签约的用户(django-oauth-toolkit为Django REST Framework提供身份validationscheme和权限类),这些用户可以正常工作。
但是,python-social-auth只实现基于会话的authentication,所以没有直接的方法来代表外部oauth2提供者注册的用户进行authentication的API请求。

如果我使用由django-oauth-toolkit生成的access_token,请执行如下的请求:

curl -v -H "Authorization: Bearer <token_generated_by_django-oauth-toolkit>" http://localhost:8000/api/ 

但是,以下方法不起作用,因为Django REST Framework没有相应的authenticationscheme,而python-social-auth提供的AUTHENTICATION_BACKENDS仅适用于基于会话的authentication:

 curl -v -H "Authorization: Bearer <token_stored_by_python-social-auth>" http://localhost:8000/api/ 

在使用python-social-auth进行身份validation后,使用Django REST Framework提供的可浏览的API工作得很好,只有没有会话cookie的API调用不起作用。

我想知道什么是最好的办法是这个问题。 我看到的方式基本上有两种select:

答:当用户使用外部oauth2提供程序注册(由python-social-auth处理)时,挂接进程以创buildoauth2_provider.models.AccessToken,并继续使用'oauth2_provider.ext.rest_framework.OAuth2Authentication' ,现在进行身份validation还有向外部提供商注册的用户。 这里build议使用此方法: https : //groups.google.com/d/msg/django-rest-framework/ACKx1kY7kZM/YPWFA2DP9LwJ

B:使用python-social-auth进行API请求authentication。 我可以通过编写一个自定义的后端和使用register_by_access_token将我自己的用户变成python-social-auth。 但是,由于API调用不能使用Django会话,这意味着我将不得不为Django Rest Framework编写一个validationscheme,该scheme利用python-social-auth存储的数据。 有关如何做到这一点的指针可以在这里find:
http://psa.matiasaguirre.net/docs/use_cases.html#signup-by-oauth-access-token
http://blog.wizer.fr/2013/11/angularjs-facebook-with-a-django-rest-api/
http://cbdev.blogspot.it/2014/02/facebook-login-with-angularjs-django.html
然而,我了解python-social-auth的方式只是在进行login时validation令牌,然后依赖于Django会话。 这意味着我将不得不find一种方法来防止python-social-auth为每个无状态API请求执行整个oauth2-flow,而是检查存储在数据库中的数据,这对于查询并不是真正优化的,因为它是存储为JSON(我可以使用UserSocialAuth.objects.get(extra_data__contains =)虽然)。
我还必须考虑validation访问令牌的范围,并使用它们来检查权限,django-oauth-toolkit已经做了一些事情( TokenHasScoperequired_scopes等)。

目前,我倾向于使用选项A,因为django-oauth-toolkit提供了与Django Rest Framework的良好集成,并且获得了我需要的一切。 唯一的缺点是我必须将由python-social-auth检索的access_tokens“注入”到django-oauth-toolkit的AccessToken模型中,这种模式在某种程度上感觉不对,但可能是迄今为止最简单的方法。

有没有人反对这样做,或者可能以不同的方式处理同样的问题? 我是否错过了明显的东西,使我的生活比必要的更难? 如果有人已经将python-social-auth和external oauth2提供程序集成到了django-oauth-toolkit中,我将非常感谢一些提示或观点。

很多实现OAuth的难点归结为认识授权stream程应该如何工作。 这主要是因为这是login的“出发点”,在使用第三方后端时(使用Python Social Auth),您实际上是这样做了两次 :一次是针对您的API,一次是针对第三方API。

使用您的API和第三方后端来授权请求

你需要的authentication过程是:

选项A的序列图

 Mobile App -> Your API : Authorization redirect Your API -> Django Login : Displays login page Django Login -> Facebook : User signs in Facebook -> Django Login : User authorizes your API Django Login -> Your API : User signs in Your API -> Mobile App : User authorizes mobile app 

我在这里使用“Facebook”作为第三方后端,但是对于任何后端,这个过程都是一样的。

从您的移动应用程序的angular度来看, 您只能redirect到由Django OAuth Toolkit提供的/authorize url 。 从那里,移动应用程序一直等到达到回叫url,就像在标准的OAuth授权stream程中一样。 几乎所有其他事情(Djangologin,社交login等)都由后台的Django OAuth Toolkit或Python Social Auth处理。

这也将与您使用的任何OAuth库几乎兼容,无论使用哪个第三方后端,授权stream程都将保持一致。 它甚至会处理(常见的)需要能够支持Django的身份validation后端(电子邮件/用户名和密码)以及第三方login的情况。

选项A没有第三方后端

 Mobile App -> Your API : Authorization redirect Your API -> Django Login : Displays login page Django Login -> Your API : User signs in Your API -> Mobile App : User authorizes mobile app 

此处还需要注意的是,移动应用程序(可以是任何OAuth客户端) 从不接收Facebook /第三方OAuth令牌 。 这非常重要,因为它确保您的API充当OAuth客户端与您用户的社交帐户之间的中介。

以您的API作为网守的序列图

 Mobile App -> Your API : Authorization redirect Your API -> Mobile App : Receives OAuth token Mobile App -> Your API : Requests the display name Your API -> Facebook : Requests the full name Facebook -> Your API : Sends back the full name Your API -> Mobile App : Send back a display name 

否则,OAuth客户端将能够绕过您的API并代表您向第三方API发出请求。

绕过您的API的序列图

 Mobile App -> Your API : Authorization redirect Your API -> Mobile App : Receives Facebook token Mobile App -> Facebook : Requests all of the followers Facebook -> Mobile App : Sends any requested data 

您会注意到,此时您将失去对第三方令牌的所有控制权 。 这是特别危险的,因为大多数代币可以访问大量的数据,这就打开了滥用的大门,最终以你的名义下落。 login到您的API /网站的用户很可能并不打算与OAuth客户端共享他们的社交信息,而是希望您保留这些信息(尽可能),而是将信息暴露给所有人

validation对您的API的请求

当移动应用程序随后使用您的OAuth令牌您的API发出请求时,所有身份validation都将在后台通过Django OAuth Toolkit(或您的OAuth提供程序)进行。 所有你看到的是有一个User与您的请求相关联。

如何验证OAuth令牌

 Mobile App -> Your API : Sends request with OAuth token Your API -> Django OAuth Toolkit : Verifies the token Django OAuth Toolkit -> Your API : Returns the user who is authenticated Your API -> Mobile App : Sends requested data back 

这很重要,因为在授权阶段之后,如果用户来自Facebook或Django的身份validation系统,则不会产生影响 。 你的API只需要一个User来处理,你的OAuth提供者应该能够处理令牌的validation和validation。

这与使用会话支持的validation时Django REST框架如何validation用户没有什么不同。

使用会话进行身份验证的序列图

 Web Browser -> Your API : Sends session cookie Your API -> Django : Verifies session token Django -> Your API : Returns session data Your API -> Django : Verifies the user session Django -> Your API : Returns the logged in user Your API -> Web Browser : Returns the requested data 

同样, 所有这些都由Django OAuth工具包处理,不需要额外的工作来实现。

使用本机SDK

在大多数情况下,您将通过自己的网站validation用户身份,并使用Python Social Auth来处理所有事情。 但是一个明显的例外是使用本地SDK,因为authentication和授权是通过本地系统来处理的 ,这意味着您完全绕过了您的API 。 对于需要使用第三方login的应用程序或根本不使用API​​的应用程序来说,这非常有用,但是当两者结合在一起时这是一场噩梦

这是因为您的服务器无法validationlogin ,并被迫认为login是有效的和真实的 ,这意味着它绕过了Python社交授权给你的任何和所有的安全性。

使用本地SDK可能会导致问题

 Mobile App -> Facebook SDK : Opens the authorization prompt Facebook SDK -> Mobile App : Gets the Facebook token Mobile App -> Your API : Sends the Facebook token for authorization Your API -> Django Login : Tries to validate the token Django Login -> Your API : Returns a matching user Your API -> Mobile App : Sends back an OAuth token for the user 

您会注意到,这会在validation阶段跳过您的API,然后强制您的API对传入的令牌进行假设。但肯定会有这种风险可能值得的情况 ,所以您应该先评估一下把它扔掉。 在用户的快速login和本地login之间进行权衡,并可能处理不良或恶意的令牌

我使用A.选项解决了这个问题。

我所做的是注册使用第三方的用户通过他们的第三方访问令牌进行注册。

 url(r'^register-by-token/(?P<backend>[^/]+)/$', views.register_by_access_token), 

这样,我可以发出一个像这样的GET请求:

GET http://localhost:8000/register-by-token/facebook/?access_token=123456

并且register_by_access_token被调用。 request.backend.do_auth会从令牌中查询提供者的用户信息,如果他已经注册了,用神奇的方法注册一个用户帐号和用户的信息或签名。

然后,我手动创build一个令牌并将其作为JSON返回,以便让客户端查询我的API。

 from oauthlib.common import generate_token ... @psa('social:complete') def register_by_access_token(request, backend): # This view expects an access_token GET parameter, if it's needed, # request.backend and request.strategy will be loaded with the current # backend and strategy. third_party_token = request.GET.get('access_token') user = request.backend.do_auth(third_party_token) if user: login(request, user) # We get our app! app = Application.objects.get(name="myapp") # We delete the old token try: old = AccessToken.objects.get(user=user, application=app) except: pass else: old.delete() # We create a new one my_token = generate_token() # We create the access token # (we could create a refresh token too the same way) AccessToken.objects.create(user=user, application=app, expires=now() + timedelta(days=365), token=my_token) return "OK" # you can return your token as JSON here else: return "ERROR" 

我只是不确定我产生令牌的方式,这是一个好的做法吗? 那么,在同一时间,它的工作!

也许django-rest-framework-social-oauth2是你正在寻找的。 这个包依赖于你已经使用的python-social-authdjango-oauth-toolkit 。 我通过文档快速扫描,似乎只是实现你正在做的事情。