{ "componentChunkName": "component---src-pages-blog-markdown-remark-fields-slug-js", "path": "/blog/oauth-2-vs-session-management", "result": {"data":{"markdownRemark":{"html":"

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.

\n

The most important difference

\n

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.

\n

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.

\n

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.

\n

\n \n \n \n \n

\n

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

\n

About Trust

\n

\n \n \n \n \n

\n

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:

\n
    \n
  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. \n
  2. Upon successful authentication, OtherApp’s backend issues a short lived access token[3] which is stored on YourApp’s frontend.
    3. \n
  3. YourApp’s frontend then uses this access token to talk to YourApp’s backend.
    4. \n
  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.
    5. \n
\n

Access pattern 1b)

\n

\n \n