yeti logo icon
Close Icon
contact us
Yeti postage stamp
We'll reply within 24 hours.
Thank you! Your message has been received!
A yeti hand giving a thumb's up
Oops! Something went wrong while submitting the form.

Summary: DRF, OAuth, and Social Authentication

By
-
June 24, 2015

Howdy, travellers. At Yeti we work on a bunch of mobile and web apps, and like most apps these days, user authentication is a requirement. I'm working on a series to demystify the process of tying together Django REST Framework, your own OAuth scheme, and using OAuth services from Facebook, Twitter, etc.

  1. Part 1: this summary
  2. Part 2: OAuth2 with Django Rest Framework - Use the OAuth2 scheme to authenticate your own users on your app (i.e., in place of token auth or session auth)
  3. Part 3: Social Auth with Django REST Framework - Authenticate your users with third-party services like Facebook, Twitter, and Google
  4. Part 4: Server vs. Client OAuth Flows - A little more explanation of how this is working, and why we are writing server code that uses the client-side auth flow
  5. Part 5: DRF and Python Social Auth: Tying It All Together - Combine parts 2 & 3 in an app where users authenticate with an OAuth scheme and link social accounts

We have also tackled some of the same problems with Tastypie. See Integrating Django, Tastypie & Python Social Auth to see a Tastypie implementation of Part 3.

My Thoughts

Frankly, after making all this work, I'm not convinced that implementing your own OAuth flow (part 2) is much more secure than using token-based authentication. We initially read some documentation that encouraged us to go down this path, but it's not up anymore, and our own thoughts are that it may be unhelpfully complex. Of course, if you're looking to set your app up as an oauth provider for other applications, this is the way to go. But serving your own client-side app with this auth scheme may not really provide any benefit. That said, you should review the authentication flows in parts 2 & 5 and decide for yourself.

If you're looking to set up something similar to part 5 (in-app oauth + social authentication) and you're not interested in how it all works, you may want to check out the descriptively named django-rest-framework-social-oauth2. I haven't used it, but it promises to do something similar to that set up.

Finally, I wrote most of this code when I had been programming for one year, and using DRF for about two weeks. I can 100% guarantee you it is not perfect, and in our fast-changing industry it may become outdated. Feel free to (politely, constructively) help me learn.

You Might also like...

code on a computerManaging Perisistent Browser Data with useSyncExternalStore

Struggling to keep React state in sync across tabs and sessions? Learn how to use useSyncExternalStore to manage state persistence with localStorage and sessionStorage—without complex state management libraries. Improve performance and streamline your app’s state logic.

software developerReact Hooks 102: When to Avoid useEffect

Overusing useEffect in React can lead to inefficient components and performance issues. In this post, learn when to avoid useEffect and discover better alternatives for managing state, calculations, and user events. Optimize your React code with best practices for cleaner, faster applications.

software developer codingFintech Security with GraphQL Shield

Securing fintech applications is crucial, and GraphQL’s flexibility can be a security risk if not properly managed. GraphQL Shield helps enforce fine-grained authorization using role-based (RBAC) and attribute-based (ABAC) access control. In this post, we’ll explore why authorization matters, how to implement secure, composable rules, and walk through a demo app showcasing best practices.

Browse all Blog Articles

Ready for your new product adventure?

Let's Get Started