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. 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. 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!
: 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.
: When describing the flows, we will not mention the authorisation code step via client secret or PKCE for brevity.
: 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