600

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.

9 Answers 9

527

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, if there are 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, the only thing a party must present to be granted access to a protected resource is the token itself, and the token in question can be called a bearer token.

In practice, what you're doing can already be classified as bearer token -based. However, do consider 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. 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)

9
  • 4
    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?
    – user805981
    Oct 12, 2017 at 22:55
  • 4
    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/… Jun 22, 2018 at 3:41
  • 4
    " 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.
    – Konrad
    Sep 5, 2018 at 7:27
  • 3
    @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. Sep 11, 2018 at 2:22
  • 3
    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.
    – Konrad
    Sep 11, 2018 at 7:19
497

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

4
  • 24
    Do oAuth protocol implementations use JWT as the token format, for most cases? If not what is most common? Nov 10, 2017 at 23:30
  • 35
    The token format in oauth is undefined, but JWT should work fine Nov 21, 2017 at 14:34
  • 4
    "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)
    – eis
    Jun 2, 2021 at 11:50
  • 1
    For a simple api, what is the risk of using the same api as the grantor of the token (on user login)?
    – variable
    Feb 5, 2022 at 8:05
206

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.

9
  • 32
    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.
    – Michael
    Oct 30, 2018 at 16:14
  • 10
    Hi @Michael there is too much misunderstanding about this. I edited my comment thank you.
    – M S
    Nov 1, 2018 at 18:08
  • 2
    Are you guys saying that Oauth is just a piece of Standards that developers should follow? Or it really is a framework? Apr 27, 2020 at 12:10
  • 1
    "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
    – GoBusto
    Sep 2, 2020 at 11:49
  • 7
    @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.
    – hfossli
    Sep 10, 2020 at 7:05
142

JWT (JSON Web Tokens)- It is just a token format. JWT tokens are JSON encoded data structures containing 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 solves a problem in which user wants to access the data using client software like browser-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.

2
  • 13
    No cookies == No CSRF protection. If you don't use cookies for authorization, then you don't have to worry about CSRF protection. Oct 18, 2019 at 11:17
  • 1
    @niranjan_harpale When I first read this "No CSRF protection", I interpreted it as "a lack of CSRF protection". Reading your next sentences makes it clear that you actually meant "no need for CSRF protection" (or "no risk of SCRF").
    – at54321
    Nov 22, 2022 at 13:09
101

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

3
  • 8
    OAuth can also be used for your own clients, not necessarily just 3rd party ones. The Password Credentials Grant type does exactly that.
    – harpratap
    Jan 12, 2018 at 2:57
  • 7
    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!
    – Vivek Goel
    Jan 7, 2020 at 18:39
  • 1
    @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.
    – Turbo
    Jun 3, 2022 at 1:39
19

find the main differences between JWT & OAuth

  1. OAuth 2.0 defines a protocol & JWT defines a token format.

  2. OAuth can use either JWT as a token format or access token which is a bearer token.

  3. OpenID connect mostly use JWT as a token format.

10

JWT is an open standard that defines a compact and self-contained way for securely transmitting information between parties. It is an authentication protocol where we allow encoded claims (tokens) to be transferred between two parties (client and server) and the token is issued upon the identification of a client. With each subsequent request we send the token.

Whereas OAuth2 is an authorization framework, where it has a general procedures and setups defined by the framework. JWT can be used as a mechanism inside OAuth2.

You can read more on this here

OAuth or JWT? Which one to use and why?

0
3

Jwt is a strict set of instructions for the issuing and validating of signed access tokens. The tokens contain claims that are used by an app to limit access to a user

OAuth2 on the other hand is not a protocol, its a delegated authorization framework. think very detailed guideline, for letting users and applications authorize specific permissions to other applications in both private and public settings. OpenID Connect which sits on top of OAUTH2 gives you Authentication and Authorization.it details how multiple different roles, users in your system, server side apps like an API, and clients such as websites or native mobile apps, can authenticate with each othe

Note oauth2 can work with jwt , flexible implementation, extandable to different applications

1
  • 1
    It appears you have this exactly backwards.
    – jbruni
    Jan 8, 2020 at 17:31
0
  • JWT tokens require, at most, a one-time communication between the resource server and the authorization server at runtime. The resource server needs to request the authorization server for the public key to decrypt the JWT tokens. This can be done at resource server startup. This can even be stored in the resource server in a properties file avoiding the query at all.

  • OAuth2 solve a problem that user wants to access the data using client software like browser-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 an access token.

  • OAuth2 can be used with JWT tokens or access token which is a bearer token.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.