

The most secure and easy to implement solution for user session management
There seems to be a lot of misinformation on when OAuth 2.0 (henceforth referred to as OAuth) is appropriate for use. A lot of developers confuse OAuth with web session management and hence end up using the wrong protocol / set of technologies. This, in turn, leads to security issues. This article will clarify when to use regular session management solutions and when to use any one of the OAuth flows.
Ideally, we would like all authenticated communication to be long lived (to provide the best user experience). The difference between user session management and OAuth is the level of trust between the communicating parties.ย
While using user sessions, it is assumed that one of the two communicating parties is untrusted (your appโs frontend) and the other party is trusted (your appโs backend). In OAuth flows, generally, the two communicating parties are both trusted (i.e. your appโs backend and third party appโs backend). In some OAuth flows, one of the two parties is also untrusted, in which case, it would require a handshake that is โshort livedโ. We will talk more about โtrusted partiesโ in the next section.ย
As a result, session management generally refers to communication between your own appโs backend and frontend. Whereas, OAuth is used when your app (frontend or backend) needs to communicate with a third partyโs backend โ if you use Google / Facebook Sign in for your app or if your app uses Okta / Auth0 for managing users.ย
Think about this like global trade. OAuth is the system that lets countries trade with each other, whereas session management is the system that enables trade within a country. You always require local trade โ regardless of whether you exchange goods (data) with other countries or not (see โOAuth depends on Session managementโ section).
Put simply, in any app, the frontend is untrusted, whereas the backend is trusted. This is because the backend is under strict control of the app developers who generally mean no harm to the users or to the app[1]. In contrast, the app developers have no control over the frontend. The frontend device could be compromised via social engineering techniques or malware, and there is nothing the app developers can do to mitigate that.ย
If a frontend is compromised, then the attacker may have an easy way to โharmโ the app or its users. Hence, it is advisable that no data being sent from the frontend be blindly trusted. We must always verify and sanitize the incoming data, and try to minimise risk as far as possible.
In order to show this dependency, letโs examine the different ways two apps can communicate with each other using the Authorization code grant flow[2]. The setup is that we have two apps: โYourAppโ and โOtherAppโ.ย
YourAppย has the following components:
OtherAppย has the following components:
Now, letโs see the different access patterns:
Access pattern 1a)
One way of doing this is to simply use session management between your frontend and backend. Another method, if you are using an external identity management solution like Okta or Auth0, is:
Access pattern 1b)
Access pattern 2a)
We can see that regardless of how two apps want to communicate with each other, there is always a need for session management.
There are numerous methods to implementing session management. Some are easier to implement, but are also less secure. Just like in OAuth, here too, the concept of short lived access and long lived refresh tokens can come into play. However, unlike OAuth, the refresh token can be sent and stored on the frontend as long as it is โone time useโ (a.k.aย rotating refresh tokens). Any other session flow is less secure as per the analysis inย this blog post.
A final difference is that OAuth and session management may use different types of tokens. In OAuth, if the access token issued by theย OtherAppย is used for communication betweenย YourAppโs frontend and backend, then this token must be a JWT. This is so thatย YourAppโs backend can verify this token without having to callย OtherAppโs backend. In fact, JWT was invented to fulfill this exact need.
In session management, the access token can be Opaque (a long, random string) or a JWT. There are pros and cons of using either of them as explained inย this blog post.
โย Developers confuse OAuth with web session management and end up using the wrong protocol & systems.
Clarify the difference โ ensure you are using the correct flow for your use case.ย โ
The core difference between OAuth and session management is one of trust. Using session management, one can maintain a long lived, authenticated connection between an untrusted party (frontend) and a trusted party (both within the same app). Whereas using OAuth, one can maintain a long lived, authenticated connection between two trusted parties โ both being the backend of different services.
If you liked this blog, you may also like other blogs from us:
Written by the Folks atย SuperTokensย โ hope you enjoyed!
[1]: Backend data breaches and insider threats do occur. However, these events are much more โcontrollableโ by app developers than, for example, a malware on the end userโs computer.
[2]: When describing the flows, we will not mention the authorisation code step via client secret or PKCE for brevity.
[3]: The backend only issues an access token since that is short lived and it cannot trust the frontend to securely store a non-changing long lived token (refresh token).
Previously published at https://supertokens.io/blog/oauth-2-vs-session-management
Create your free account to unlock your custom reading experience.