What is the difference between OAuth based and Token based authentication?

Question

I thought that OAuth is basically a token based authentication specification but most of the time frameworks act as if there is a difference between them. For example, as sh

Answer 1

OAuth is a specification for authorization not authentication

OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:

The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.

Only use OAuth if you want to give access to a third party service to your apis. Even when you are using OAuth you would need some kind of authentication (token based or session based etc) to authenticate the uses. OAuth is not designed for authentication.

see this question.

Answer 2

When you are requesting resource from a secured web service, you can provide an authentication token on the call. The token acts as "secret code" for accessing the resource.

OAuth is just specific type of token based authentication method.

Answer 3

This is a good question -- there is a lot of confusion around tokens and OAuth.

First up, when you mention OAuth, you are likely referring to the OAuth2 standard. This is the latest version of the OAuth protocol, and is what most people are specifically talking about when they say 'OAuth'.

The OAuth protocol supports several different types of authentication and authorization (4 to be precise).

Secondly, the OAuth protocol works by authenticating users via tokens. The idea here is this:

Instead of having your user send their actual credentials to your server on every single request (like they would with Basic Auth, where a user sends their username/password to the server for each request), with OAuth you first exchange your user credentials for a 'token', and then authenticate users based on this 'token'.

The idea of OAuth is that by requiring users to pass their confidential credentials over the network less frequently, less bad things can happen. (This is the idea, anyhow.)

Now, here's where tokens come into play: the OAuth spec is built around the concept of tokens, but DOES NOT SPECIFY WHAT A TOKEN IS.

In the most 'general' sense, a token is just a string that uniquely identifies a user. That's it.

People realized this, and developed a new standard for creating tokens, called the JSON Web Token standard. This standard basically provides a set of rules for creating tokens in a very specific way, which makes tokens more useful for you in general.

JWTs let you do things like:

• Cryptographically sign a token so you know that a token wasn't tampered with by a user.
• Encrypt tokens so the contents cannot be read in plain text.
• Embed JSON data INSIDE of a token string in a standard way.

Now, for the most part: pretty much everyone in the development community has agreed that if you're using any sort of OAuth, then the tokens you're using should be JSON Web Tokens.

==========

OK! Now that we've covered the backstory, let me answer your question.

The choice you're making above is whether or not you want to enable the full OAuth2 specification for authentication / authorization (which is quite complex), or whether you simply want some basic 'token authentication'.

Because the OAuth protocol provides multiple different ways to authenticate in a STANDARDS COMPLIANT way, it adds a lot of complexity to most authentication systems.

Because of this, a lot of frameworks offer a 'dumbed down' version of the OAuth2 Password Grant flow, which essentially is a simple method where:

• A user sends their username/password to your server at some URL like /login.
• Your server generates a JWT token for the user.
• Your server returns that token to the user.
• The user stores this token in their cookies, mobile device, or possible API server, where they use it to make requests.

Again: the flow above is NOT OAuth compliant, but is a slightly simpler version that STILL uses tokens.

The main point here is that tokens (JWTs) are generally useful, and don't NEED to be paired with the OAuth flow.

I realize this is a wall of text, but hopefully it answers your question in more depth =)