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. The most important difference 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). About Trust 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. [1] 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. OAuth depends on Session management 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: “ ” and “ ”. [2] YourApp OtherApp has the following components: YourApp A frontend (untrusted) An optional backend server has the following components: OtherApp A frontend (untrusted) A backend Now, let’s see the different access patterns: has a backend server a.) ’s frontend wants to access ’s backend server b.) ’s frontend / backend wants to access ’s backend server. YourApp YourApp YourApp YourApp OtherApp doesn’t have a backend server a.) ’s frontend wants to access ’s backend server YourApp YourApp OtherApp 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: ’s frontend redirects the user to (1.1) where the user logs into ’s frontend which talks to its backend via (1.2) YourApp OtherApp OtherApp session management . Upon successful authentication, ’s backend issues a short lived access token which is stored on ’s frontend. OtherApp [3] YourApp ’s frontend then uses this access token to talk to ’s backend. YourApp YourApp When this access token expires, the user is redirected to ’s frontend. If the session between ’s frontend and backend is still alive, then a new access token is immediately issued to ’s frontend, (via the authorisation code) otherwise, the user must login again. OtherApp OtherApp YourApp Access pattern 1b) The user logs into ’s backend via ’s frontend. Data between the two is exchanged via . YourApp YourApp session management The user authenticates themselves (after a redirection – 2.1) on ’s frontend, which talks to its backend via (2.2). OtherApp session management Upon successful authentication, ’s backend issues a short lived access token (stored on ’s frontend and / or backend) and a long lived refresh token (stored only in ’s backend, which is trusted). OtherApp YourApp YourApp ’s frontend / backend can now use the access token to talk to ’s backend. When the access token expires, ’s backend can use the refresh token to get a new access token (which can then be sent to ’s frontend). YourApp OtherApp YourApp YourApp Access pattern 2a) ’s frontend redirects the user to (1.1) where the user logs into ’s frontend which talks to its backend via (1.2) YourApp OtherApp OtherApp session management . Upon successful authentication, ’s backend issues a short lived access token which is stored on ’s frontend. OtherApp [3] YourApp ’s frontend then uses this access token to talk to ’s backend. YourApp OtherApp When this access token expires, the user is redirected to ’s frontend. If the session between ’s frontend and backend is still alive, then a new access token is immediately issued to ’s frontend, (via the authorisation code) otherwise, the user must login again. OtherApp OtherApp YourApp We can see that regardless of how two apps want to communicate with each other, there is always a need for session management. 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 ). Any other session flow is less secure as per the analysis in . rotating refresh tokens this blog post Difference in token types A final difference is that OAuth and session management may use different types of tokens. In OAuth, if the access token issued by the is used for communication between ’s frontend and backend, then this token must be a JWT. This is so that ’s backend can verify this token without having to call ’s backend. In fact, JWT was invented to fulfill this exact need. OtherApp YourApp YourApp OtherApp 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. Conclusion 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: All you need to know about user session security The best way to securely manage user sessions Written by the Folks at — hope you enjoyed! SuperTokens Footnotes : 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. [1] : When describing the flows, we will not mention the authorisation code step via client secret or PKCE for brevity. [2] : 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). [3] Previously published at https://supertokens.io/blog/oauth-2-vs-session-management

Flow

Facebook

Google

How to Implement a Forgot Password Flow (With Pseudo Code)

Are you using JWTs for user sessions in the correct way?

See our website for repositories

Nominated for 2022 - HackerNoon Contributor of the Year - Security

Nominated for 2022 - HackerNoon Contributor of the Year - Authentication

Nominated for 2022 - HackerNoon Contributor of the Year - Open Source

Too Long; Didn't Read

The Difference Between OAuth 2.0 And Session Management

The Difference Between OAuth 2.0 And Session Management

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

All you need to know about user session security

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

All you need to know about user session security

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps