What are the main differences between JWT and OAuth authentication?

Question

I have a new SPA with a stateless authentication model using JWT. I am often asked to refer OAuth for authentication flows like asking me to send 'Bearer tokens' for every request instead of a simple token header but I do think that OAuth is a lot more complex than a simple JWT based authentication. What are the main differences, should I make the JWT authentication behave like OAuth?

I am also using the JWT as my XSRF-TOKEN to prevent XSRF but I am being asked to keep them separate? Should I keep them separate? Any help here will be appreciated and might lead to a set of guidelines for the community.

Solution 1

TL;DR If you have very simple scenarios, like a single client application, a single API then it might not pay off to go OAuth 2.0, on the other hand, lots of different clients (browser-based, native mobile, server-side, etc) then sticking to OAuth 2.0 rules might make it more manageable than trying to roll your own system.

---

As stated in another answer, JWT (Learn JSON Web Tokens) is just a token format, it defines a compact and self-contained mechanism for transmitting data between parties in a way that can be verified and trusted because it is digitally signed. Additionally, the encoding rules of a JWT also make these tokens very easy to use within the context of HTTP.

Being self-contained (the actual token contains information about a given subject) they are also a good choice for implementing stateless authentication mechanisms (aka Look mum, no sessions!). When going this route and the only thing a party must present to be granted access to a protected resource is the token itself, the token in question can be called a bearer token.

In practice, what you're doing can already be classified as based on bearer tokens. However, do consider that you're not using bearer tokens as specified by the OAuth 2.0 related specs (see RFC 6750). That would imply, relying on the Authorization HTTP header and using the Bearer authentication scheme.

Regarding the use of the JWT to prevent CSRF without knowing exact details it's difficult to ascertain the validity of that practice, but to be honest it does not seem correct and/or worthwhile. The following article (Cookies vs Tokens: The Definitive Guide) may be a useful read on this subject, particularly the XSS and XSRF Protection section.

One final piece of advice, even if you don't need to go full OAuth 2.0, I would strongly recommend on passing your access token within the Authorization header instead of going with custom headers. If they are really bearer tokens, follow the rules of RFC 6750. If not, you can always create a custom authentication scheme and still use that header.

Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers.

(source: RFC 6819, section 5.4.1)

Solution 2

OAuth 2.0 defines a protocol, i.e. specifies how tokens are transferred, JWT defines a token format.

OAuth 2.0 and "JWT authentication" have similar appearance when it comes to the (2nd) stage where the Client presents the token to the Resource Server: the token is passed in a header.

But "JWT authentication" is not a standard and does not specify how the Client obtains the token in the first place (the 1st stage). That is where the perceived complexity of OAuth comes from: it also defines various ways in which the Client can obtain an access token from something that is called an Authorization Server.

So the real difference is that JWT is just a token format, OAuth 2.0 is a protocol (that may use a JWT as a token format).

Solution 3

Firstly, we have to differentiate JWT and OAuth. Basically, JWT is a token format. OAuth is an authorization protocol that can use JWT as a token. OAuth uses server-side and client-side storage. If you want to do real logout you must go with OAuth2. Authentication with JWT token can not logout actually. Because you don't have an Authentication Server that keeps track of tokens. If you want to provide an API to 3rd party clients, you must use OAuth2 also. OAuth2 is very flexible. JWT implementation is very easy and does not take long to implement. If your application needs this sort of flexibility, you should go with OAuth2. But if you don't need this use-case scenario, implementing OAuth2 is a waste of time.

XSRF token is always sent to the client in every response header. It does not matter if a CSRF token is sent in a JWT token or not, because the CSRF token is secured with itself. Therefore sending CSRF token in JWT is unnecessary.

Solution 4

JWT (JSON Web Tokens)- It is just a token format. JWT tokens are JSON encoded data structures contains information about issuer, subject (claims), expiration time etc. It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).

OAuth2 - OAuth2 solve a problem that user wants to access the data using client software like browse based web apps, native mobile apps or desktop apps. OAuth2 is just for authorization, client software can be authorized to access the resources on-behalf of end user using access token.

OpenID Connect - OpenID Connect builds on top of OAuth2 and add authentication. OpenID Connect add some constraint to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers and session management. JWT is the mandatory format for the token.

CSRF protection - You don't need implement the CSRF protection if you do not store token in the browser's cookie.

Solution 5

It looks like everybody who answered here missed the moot point of OAUTH

From Wikipedia

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.[1] This mechanism is used by companies such as Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.

The key point here is access delegation. Why would anyone create OAUTH when there is an id/pwd based authentication, backed by multifactored auth like OTPs and further can be secured by JWTs which are used to secure the access to the paths (like scopes in OAUTH) and set the expiry of the access

There's no point of using OAUTH if consumers access their resources(your end points) only through their trusted websites(or apps) which are your again hosted on your end points

You can go OAUTH authentication only if you are an OAUTH provider in the cases where the resource owners (users) want to access their(your) resources (end-points) via a third-party client(external app). And it is exactly created for the same purpose though you can abuse it in general

Another important note:
You're freely using the word authentication for JWT and OAUTH but neither provide the authentication mechanism. Yes one is a token mechanism and the other is protocol but once authenticated they are only used for authorization (access management). You've to back OAUTH either with OPENID type authentication or your own client credentials

View more solutions

Comments

[user805981]

Does this mean if I use JWT authentication on a mobile app, I don't need to include CSRF on its POST request? Unlike web interface with forms?

[James Wierzba]

Do oAuth protocol implementations use JWT as the token format, for most cases? If not what is most common?

[vikingsteve]

The token format in oauth is undefined, but JWT should work fine

[harpratap]

OAuth can also be used for your own clients, not necessarily just 3rd party ones. The Password Credentials Grant type does exactly that.

[Siddharth Jain]

Cookies vs Tokens: The Definitive Guide , i.e auth0.com/blog/cookies-vs-tokens-definitive-guide isnt working This is another great discussion post : stackoverflow.com/questions/37582444/…

[Konrad]

" they are also a good choice for implementing stateless authentication mechanisms (aka Look mum, no sessions!). " If you need a way to invalidate the token because let's say it was leaked or intercepted or the user simply logged out and removing the token is not secure enough because the token is still valid then you need to store them in some database, so I think there must be some notion of session on the server for security purposes or simple token blacklist. You might say use "refresh" tokens for this. But refresh tokens can be intercepted too and consequences are much worse.

[Venkatesh Laguduva]

@Konrad, I did implement a similar mechanism which stored the unused valid tokens in a table, release them from there when they expire. For each incoming request, I have written code to cross check the incoming token against the "unused valid tokens". Even though it works, I always had my doubts - there should be a better way to handle unused but still valid tokens.

[Konrad]

@TechJunkie I don't think there is. But I think databases like redis with EXPIRE are good for this. In this kind of situations, you need fast access.

[Konrad]

No matter if you use refresh tokens or access tokens if any of them leak it involves storing them somewhere. Even if there are no invalidated tokens it still requires to query database each time.

[Konrad]

On the other hand refresh tokens just complicate implementation of the client. Because if your access token expires you need to handle that, user will be pissed if you will just log him out without any possibility of even manual refresh of the session(like banks do). It's slightly more work to do, also using standard ways of authentication (OID) and authorization(OAuth) can very often be an overkill.

[Michael]

I don't understand why this answer has a lot of upvotes, it states that "OAuth is an authentication framework" and this is completely wrong. OAuth is an authorization protocol and only an authorization protocol.

[Melikşah Şimşek]

Hi @Michael there is too much misunderstanding about this. I edited my comment thank you.

[niranjan_harpale]

No cookies == No CSRF protection. If you don't use cookies for authorization, then you don't have to worry about CSRF protection.

[Vivek Goel]

I was looking for google for such a concrete answer but could not find one. Everyone was just talking about definitions e.g. token vs protocol. Your answer explained the true purpose of using one above the other. Thank you so much!

[jbruni]

It appears you have this exactly backwards.

[StormTrooper]

Are you guys saying that Oauth is just a piece of Standards that developers should follow? Or it really is a framework?

[joedotnot]

@Konrad "manual refresh of the session(like banks do)" So you are saying banks definitely use server-side sessions? What else do they use - is it some highly secret custom mechanism? I never worked at a bank, anyone that has can chime in too.

[Konrad]

@joedotnot depends on the bank, I know one bank that does that and allows you to manually refresh the session with a click of the button. Usually, you've got a session lifetime on that kind of website in case you forgot to logout.

[GoBusto]

"If you want to do real logout you must go with OAuth2" -- Not true. For example, Devise-JWT is a non-OAuth solution that provides "log out" functionality by invalidating tokens: github.com/waiting-for-dev/devise-jwt#revocation-strategies

[Melikşah Şimşek]

Storing jwt token in database is not jwt standard. You can keep track everything not only jwt in your db and check it if token equal or not then authorize the request.But oauth2 implementation requires db track of oauth2 tokens. As I mentioned in oauth2 implementation you can use jwt token and it will keep track in db and check in every request.

[hfossli]

@Michael, that's not entirely correct. The RFC is titled "The OAuth 2.0 Authorization Framework" so I guess that leaves some confusion as well ;) tools.ietf.org/html/rfc6749. I get what you mean though.

[Faither]

@hfossli Just wanted to send the same, but noticed you have sent the specification link, already. Why is it called a framework then and not protocol?

[Faither]

Also, related: tools.ietf.org/html/rfc6749#section-1.8 This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. For example, the OIDC extension.

[hfossli]

@F8ER the term "framework" is also a non-technical term which can be used in many situations.

[eis]

"Bearer Tokens are the predominant type of access token used with OAuth 2.0. A Bearer Token is an opaque string, not intended to have any meaning to clients using it. Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens." @JamesWierzba (source)

[variable]

For a simple api, what is the risk of using the same api as the grantor of the token (on user login)?

[Turbo]

@harpratap it can do doesn't mean we should do. I think the point he mentioned here is that it might not be worth it to implement oauth if you have only trusted clients. Yes you can implement oauth for this scenario but implementing JWT is much more simpler to acheive the same purpose.