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.

Client vs. Server OAuth Flows with REST APIs

June 16, 2015

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

Server-side oauth flow

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:

  1. You have a (Django) application and you want to let users sign up with Facebook. So, you, the developer, go to Facebook and sign up your Django app. You will specify something called a redirect uri. Facebook will assign your app a client id and client secret.
  2. Ellen Ripley comes to your site. She decides she wants to sign up using Facebook. ER clicks a button to "sign up with facebook". The button sends her on a journey.
  3. Specifically, the button sends her to some Facebook url that is specific to your Django app. It will look something like
  4. When Ellen arrives at that url, Facebook asks if she wants to approve your Django app. She does.
  5. Once she approves your app, Facebook sends her back to your Django site. How do they know where to send her? Wherever it was you specified in step 1 as your redirect uri.
  6. But wait, there's more! Facebook didn't just send ER back to the redirect uri. They sent her back with extra info. The url facebook sent her to will look something like:, where the extra info contains an authorization code.
  7. Your Django app will take that extra info and go to another facebook url. This will look something like:, and it will pass the extra info from step 6 back to facebook. Essentially you trade the authorization code for an access token.
  8. If everything has gone well so far, facebook will respond with ER's access token! This is it, this is what you've been waiting for. The access token is exactly what it sounds like -- it gives you access to ER's info. Now if you want to get some of ER's info (email address, profile picture), or do something on her behalf (make a post), you can do it with the access token.

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.

Client-side oauth flow

The client-side flow is pretty similar, but in step 6, instead of receiving an authorization code, you directly receive the user's access token. The other difference is that steps 2-6 will happen client-side in your JavaScript or mobile app. You shouldn't use the server flow client-side because at some point (usually in step 3) you will pass up your app's client secret. Your secret key should NEVER be put in a front-end application.

oauth flow comparison

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.

Using the access token

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.

You Might also like...

Shopify Checkout Using UI Extensions

At Yeti we recently created a custom Shopify App using Checkout UI extensions to pull real-time data from a client’s Enterprise Resource Planning (ERP) system into Shopify. By the end of this article you will better understand what Shopify Checkout UI extensions are, how to approach building them, and some of the things to keep in mind during the implementation process.

colorful swirlsAn Introduction to Neural Networks

Join James McNamara in this insightful talk as he navigates the intricate world of neural networks, deep learning, and artificial intelligence. From the evolution of architectures like CNNs and RNNs to groundbreaking techniques like word embeddings and transformers, discover the transformative impact of AI in image recognition, natural language processing, and even coding assistance.

A keyboardThe Symbolicon: My Journey to an Ineffective 10-key Keyboard

Join developer Jonny in exploring the Symbolicon, a unique 10-key custom keyboard inspired by the Braille alphabet. Delve into the conceptualization, ideas, and the hands-on process of building this unique keyboard!

Browse all Blog Articles

Ready for your new product adventure?

Let's Get Started