Before you go, check out these stories!

0
Hackernoon logoThe Difference Between OAuth 2.0 And Session Management by@supertokens.io

The Difference Between OAuth 2.0 And Session Management

Author profile picture

@supertokens.ioSuperTokens

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.

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

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[2]. The setup is that we have two apps: โ€œYourAppโ€ and โ€œOtherAppโ€.ย 

YourAppย has the following components:

  • A frontend (untrusted)
  • An optional backend server

OtherAppย has the following components:

  • A frontend (untrusted)
  • A backend

Now, letโ€™s see the different access patterns:

  1. YourAppย has a backend server
    ย  ย  ย  a.)ย YourAppโ€™sย frontend wants to accessย YourAppโ€™sย backend server
    ย  ย  ย  b.)ย YourAppโ€™sย frontend / backend wants to accessย OtherAppโ€™sย backend server.
  2. YourAppย doesnโ€™t have a backend server
    ย  ย  ย  a.)ย YourAppโ€™sย frontend wants to accessย OtherAppโ€™s backend server

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:

  1. YourAppโ€™s frontend redirects the user toย OtherAppย (1.1) where the user logs intoย OtherAppโ€™s frontend which talks to its backend viaย session managementย (1.2).
  2. Upon successful authentication,ย OtherAppโ€™s backend issues a short lived access token[3]ย which is stored onย YourAppโ€™s frontend.
  3. YourAppโ€™s frontend then uses this access token to talk toย YourAppโ€™s backend.
  4. When this access token expires, the user is redirected toย OtherAppโ€™s frontend. If the session betweenย OtherAppโ€™s frontend and backend is still alive, then a new access token is immediately issued toย YourAppโ€™s frontend, (via the authorisation code) otherwise, the user must login again.

Access pattern 1b)

  1. The user logs intoย YourAppโ€™s backend viaย YourAppโ€™s frontend. Data between the two is exchanged viaย session management.
  2. The user authenticates themselves (after a redirection โ€“ 2.1) onย OtherAppโ€™s frontend, which talks to its backend viaย session managementย (2.2).
  3. Upon successful authentication,ย OtherAppโ€™s backend issues a short lived access token (stored onย YourAppโ€™s frontend and / or backend) and a long lived refresh token (stored only inย YourAppโ€™s backend, which is trusted).
  4. YourAppโ€™s frontend / backend can now use the access token to talk toย OtherAppโ€™s backend. When the access token expires,ย YourAppโ€™s backend can use the refresh token to get a new access token (which can then be sent toย YourAppโ€™s frontend).

Access pattern 2a)

  1. YourAppโ€™s frontend redirects the user toย OtherAppย (1.1) where the user logs intoย OtherAppโ€™s frontend which talks to its backend viaย session managementย (1.2).
  2. Upon successful authentication,ย OtherAppโ€™s backend issues a short lived access token[3]ย which is stored onย YourAppโ€™s frontend.
  3. YourAppโ€™s frontend then uses this access token to talk toย OtherAppโ€™s backend.
  4. When this access token expires, the user is redirected toย OtherAppโ€™s frontend. If the session betweenย OtherAppโ€™s frontend and backend is still alive, then a new access token is immediately issued toย YourAppโ€™s frontend, (via the authorisation code) otherwise, the user must login again.

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ย rotating refresh tokens). Any other session flow is less secure as per the analysis inย 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ย 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.ย 
โ€

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:

Written by the Folks atย SuperTokensย โ€” hope you enjoyed!

Footnotes

[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

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.