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 shown in the picture below Jhipster asks whether to use an OAuth based or a token based authentication.

Aren't these the same thing ? What exactly is the difference since both includes tokens in their implementations ?

Solution 1

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 =)

Solution 2

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.

Solution 3

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.

Comments

[Spomky-Labs]

Good answer, but it should be mentionned that OAuth2 itself cannot be used to authenticate users (the client knows nothing about the user unless an API endpoint is available). OpenID Connect must be implemented to perform authentication based on OAuth2

[rdegges]

This is correct. I didn't elaborate on that because I didn't want to overly confuse the OP. But you are 100% correct.

[hattenn]

@rdegges, could you explain why the simple flow you explained is not OAuth compliant? What would you need to add to it to make it OAuth compliant?

[RayLoveless]

@hattenn here's an artical (oauth.net/articles/authentication) that provides some details on why it's not oAuth compliant:

[David]

@RayLoveless I read that article but I'm still not sure exactly why the above bullet point isn't OAuth2 compliant for the Password grant flow. Could you elaborate?

[rdegges]

@skaterdav85 it's because OAuth specifies a URL that needs to serve the request (/oauth/token), as well as specific query params and body params for the field names. It's very specific.

[Nithin]

This answer is misleading. Oauth is not an authentication framework, it is an authorization framework.

[rdegges]

I've already addressed this above @nithin -- I purposefully called it that to simplify the understanding for readers.

[Mikz]

@rdegges OAuth does not send the password to the server. It asks the user for authenticating their basic information from another server. Eg: spotify uses Facebook API to access your user name and Profile picture. In this case, spotify sends an authorization request and in parallel you grant permission to the same, then the authorization is granted and sent to spotify, and receives an token , that allows you to access only the username and profile picture in this case. Now Spotify receives only username and profile picture from FB and is displayed in the UI

[rdegges]

@Mikz you are incorrect. It depends on what type of OAuth you are using. There are different grant types, and they are used in different ways. Because of the question that OP asked, i included details about the client credentials grant type which is what his question was referring to. There are obviously other modes as well, but all of them involve credentials at the IDP.

[Mikz]

@rdegges Thank you for the clarification. I was following an tutorial and came across that statement. Sorry, if it was confusing

[Klyuch]

Cool explanation in one place, thanks! I have all these thoughts in a mess but now I see it in order.

[fkotsian]

This. This. A thousand times this. 🙏 🙏