Token Authentication or OAuth 2 for Django Rest Framework API (Or Both?)

4
votes

I'm setting up a new API using Django REST Framework, and I'm a bit confused how to set up authentication. The API I'm setting up is consumed by the public, whom I want to have the most flexibility possible.

Out of the box, DRF provides Basic Authentication, Session Authentication and Token Authentication. Using another package, you can also add OAuth2 authentication.

If I set up my API to have Token Authentication -- which is included out of the box -- why do I need to set up OAuth2? I've read a bit about this, but since DRF's Token Auth is fairly custom, I haven't been able to find much comparing the two approaches.

From what I can tell, OAuth is just an advanced form of Token Auth, so why bother installing and configuring it?

1
authenticationoauth-2.0django-rest-framework
Oauth gives users the convenience of logging into your website without creating a new user name and password. They log into google (or facebook, or whomever) and google tells you they are who they say they are. This means that they don't have to create and remember a new password for your site (best case) or they minimize your liability for securely handling their passwords (pw reuse..). If crackers attack your site, they only gain access to your site, since they only have a token from google to your site. Not a username and password to all sites that the user reused their password on. – Ross Rogers
That seems to be a use case for OAuth, yeah, but in the context of an API, I'm not sure that's right. I've posted an answer below though, with my current understanding. – mlissner

1 Answers

6
votes

I was fleetingly familiar with OAuth2, but had to do a little homework to think this one through. The advantage of OAuth over the token auth that is built in is that OAuth can be negotiated by a computer, provides a distinct token per client, and can easily be revoked.

So, if I set up OAuth as an authentication on my API, that'd let you delegate a third party to use your data. For example, Twitter has OAuth, so you can set up a third party client -- Tweetie or whatever -- with an OAuth token that it can use to access your data. However, if you stop using Tweetie, or you stop trusting Tweetie, you can revoke it's OAuth access without resetting your password and thus revoking access from every client that's configured.

So in my case, I have a mostly read API, and there aren't (yet) resources that are private to particular users. As a result, we have no need for OAuth, since we don't anticipate people needing to give their passwords to third party clients.