This post is part 4 of a series on using OAuth with Django REST Framework. Part 2 focused on setting up your own OAuth2 server for your application, part 3 demonstrated integrating DRF with Python social auth, and part 5 is about integrating parts 1 & 2. For a summary of my thoughts on the process, see the series overview.
One point that may have been confusing from part 3 of this series is that from the social authentication standpoint, we are using the client-side, aka implicit, oauth flow. Since I'm focusing on writing a server-side Django app, that isn't very intuitive. However, when you're writing a REST API with the likes of DRF or Tastypie, and a separate front-end app (iOS, Android, JS, etc.), that is exactly what you need to be doing. Let's review the differences
OAuth is pretty confusing (to me at least). Many people on the internet have come up with better explanations, but here's a recap of a server-side oauth flow:
Most of the oauth explanations I've read have focused on this flow. Let's take a look at a client-side (implicit) auth flow now.
Since both flows get you to the same eventual place (an access token) you may be wondering why to use one versus the other. It's really about where you want the code for steps 2-6 to live. In a mobile app, it makes most sense for that to be in the mobile app. You could do it all server-side if you decided to embed a webview in your app. Similarly, a web app could use a JS front-end, or you could go with a more traditional app using all Django templates, and then you would use the server-side flow.
Now you have an access token, what are you supposed to do with it? Save it! Once your front-end receives the access token, you should pass that to the server to be associated with a user in your database. You will use this access token to request user data from the social service in the future. If you don't save the token, or when the token expires, the user will have to go through the process again to get a new token. So, to be clear, in part 3 of this series, the entire authentication flow takes place client-side. The work that python social auth is handling is:
Stay tuned for the final post in this series, incorporating what we've covered in the last few posts.
At our last Django Meetup Group event, Jayden Windle, the lead engineer at Jetpack, an on demand delivery company, talks building APIs with Django and GraphQL. Watch the video to learn more.
At the last meeting of the San Francisco Django Meetup Group, Wes Kendall gave a talk on how to make a bulletproof Django application by testing it with pytest. Check out his talk here!
Part of the Yeti Lunch and Learn series - our amazing developer, Resdan, gives a presentation on creating a reusable component library. Enjoy the video!