首页 文章

如何在Python Social Auth中使用Django OAuth Toolkit?

提问于
浏览
47

我正在使用Django Rest Framework构建API . 之后这个API应该被iOS和Android设备使用 . 我希望允许我的用户注册Facebook和Google等oauth2提供商 . 在这种情况下,他们根本不必在我的平台上创建一个帐户 . 但是,如果没有Facebook / Google帐户,用户也应该能够注册,我正在使用django-oauth-toolkit,所以我有自己的oauth2-provider .

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

我希望客户端使用bearer令牌进行身份验证,这对于使用我的提供者注册的用户来说很好(django-oauth-toolkit为Django REST Framework提供了身份验证方案和权限类) .
但是,python-social-auth仅实现基于会话的身份验证,因此没有直接的方法来代表由外部oauth2提供程序注册的用户进行身份验证的API请求 .

如果我使用由django-oauth-toolkit生成的access_token,那么执行这样的请求是有效的:

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

但是,由于Django REST Framework没有相应的身份验证方案,并且python-social-auth提供的AUTHENTICATION_BACKENDS仅适用于基于会话的身份验证,因此以下情况不起作用:

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

在使用python-social-auth进行身份验证后,使用Django REST Framework提供的可浏览API工作正常,只有没有会话cookie的API调用才能正常工作 .

我想知道这个问题的最佳方法是什么 . 我看待它的方式,我基本上有两个选择:

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

B:使用python-social-auth进行API请求验证 . 通过编写自定义后端并使用register_by_access_token,我可以让自己的用户进入python-social-auth . 但是,由于API调用无法使用Django会话,这意味着我必须为Django Rest Framework编写一个使用python-social-auth存储的数据的身份验证方案 . 有关如何执行此操作的一些建议可以在这里找到:
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仅在进行登录时验证令牌并且之后依赖于Django会话 . 这意味着我必须找到一种方法来防止python-social-auth为每个无状态API请求执行整个oauth2-flow,而是检查存储在数据库中的数据,这些数据不是't really optimized for querying since it'存储为JSON(我可以尽管使用UserSocialAuth.objects.get(extra_data__contains =) .
我还需要注意验证访问令牌的范围并使用它们来检查权限,django-oauth-toolkit已经做了( TokenHasScoperequired_scopes 等) .

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

有没有人反对这样做或者可能以不同的方式处理同样的问题?我错过了一些明显的东西,让我的生活变得更加艰难吗?如果有人已经将django-oauth-toolkit与python-social-auth和外部oauth2提供程序集成,我将非常感谢一些指示或意见 .

3 回答

  • 9

    实现OAuth的许多困难归结为理解授权流程应该如何工作 . 这主要是因为这是用于登录的"starting point",当使用第三方后端(使用像Python Social Auth这样的东西)时,您实际上是这样做了两次:一次用于API,一次用于第三方API .

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

    您需要的身份验证过程是:

    Sequence diagram for option 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"作为第三方后端,但任何后端的过程都是相同的 .

    从您的手机的角度来看app, you are only redirecting to the /authorize url provided by Django OAuth Toolkit . 从那里开始,移动应用程序会等到达到回调网址,就像在标准OAuth授权流程中一样 . 几乎所有其他东西(Django登录,社交登录等)都由Django OAuth Toolkit或Python Social Auth在后台处理 .

    这也将与您使用的几乎任何OAuth库兼容,无论使用何种第三方后端,授权流都将起作用 . 它甚至可以处理(常见)需要能够支持Django的身份验证后端(电子邮件/用户名和密码)以及第三方登录的情况 .

    Option A without a third-party backend

    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客户端) never receives the Facebook/third-party OAuth tokens . 这非常重要,因为它可以确保您的API充当OAuth客户端与您用户的社交帐户之间的中介 .

    Sequence diagram with your API as the gatekeeper

    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发出请求 .

    Sequence diagram for bypassing your 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
    

    你会注意到 you would have lost all control over the third-party tokens . 这是特别危险的,因为大多数令牌可以访问各种数据,这打开了滥用的大门,最终以您的名义下降 . 最有可能的是,那些登录到您的API /网站的人并不打算与OAuth客户端共享他们的社交信息,而是期望您将该信息保密(尽可能多),但是 instead you are exposing that information to everyone .

    验证对API的请求

    当移动应用程序随后使用您的OAuth令牌向您的API发出请求时,所有身份验证都会在后台通过Django OAuth Toolkit(或您的OAuth提供商)进行 . All you see is that there is a User associated with your request.

    How OAuth tokens are validated

    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
    

    这很重要,因为 after the authorization stage it shouldn't make a difference if the user is coming from Facebook or Django's authentication system . 您的API只需要 User 即可使用,您的OAuth提供商应该能够处理令牌的身份验证和验证 .

    这与Django REST框架在使用会话支持的身份验证时对用户进行身份验证的方式没有太大区别 .

    Sequence diagram for authenticating using sessions

    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
    

    同样, all of this is handled by Django OAuth Toolkit 并且不需要额外的工作来实现 .

    使用本机SDK

    在大多数情况下,您将通过自己的网站对用户进行身份验证,并使用Python Social Auth来处理所有内容 . 但是一个值得注意的例外是当使用原生SDK时,如 authentication and authorization is handled through the native system ,这意味着 you are bypassing your API entirely . 这非常适合需要与第三方登录的应用程序,或者根本不使用您的API的应用程序,但是 it's a nightmare when both come together .

    这是因为 your server can't validate the login 并被强制为 assume that the login is valid and genuine ,这意味着它绕过了Python Social Auth为您提供的所有安全性 .

    Using a native SDK can cause issues

    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
    

    您会注意到,这会在身份验证阶段跳过您的API,然后强制您的API对传入的令牌进行假设 . 但是肯定会出现 this risk may be worth it 的情况,所以您应该在抛出之前对其进行评估 . 这是 quick and native logins for your userpotentially handling bad or malicious tokens 之间的权衡 .

  • 85

    我用你的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 将从令牌中查询提供者的用户信息,并用信息神奇地注册用户帐户,或者如果他已经注册,则登录用户 .

    然后,我手动创建一个令牌并将其作为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"
    

    我只是不确定我生成令牌的方式,这是一个好习惯吗?嗯,与此同时,它的作品!

  • 5

    也许django-rest-framework-social-oauth2正是你要找的 . 此程序包取决于您已使用的 python-social-authdjango-oauth-toolkit . 我快速扫描了文档,似乎只是实现了你想要做的事情 .

相关问题