Oauth2 explained by concert ticket analogy

In order to understand OAuth2 authentication, you must get familiar with the terminology. Because terms like resource owner are rather vague at first, I use a concert ticket analogy to explain it to you.

A quick overview:

These are the essential players in OAuth2 authentication. They are explained further in the article.

  • resource owner = you (mostly)
  • client = app/website
  • auth server = token creator
  • resource server = data creator (or the server with the data you need, but the data is secured)

Using the concert ticket anology

  1. You (=resource owner) buy a ticket (=token) from a vendor (=auth server).
  2. You tell the vendor which gig you want to see (=scope)
  3. The ticket (=token) is only valid at a certain time, and only to that particular concert
  4. Next, you go to the concert venue (= resource server), and you show your ticket (=token).
  5. Eventually, the security guy (= resource server) checks if your ticket is valid, and lets you in to see the concert (= the data you want).
  • If you forge a ticket, or go with a different ticket, you won’t get access (well, unless you are very inventive).
  • You keep the ticket in your wallet because that’s the safest (=https), you don’t leave it in the middle of the street where a thief can see and steal it (=http)
  • It is likely in some cases that the auth server and the resource server are the same server (like you’d buy a ticket at the venue), but it’s not always the case.

Using computer world analogy

  • In computerworld, you’re on a website or app (=client) and the client needs some data from another server (perhaps it wants your Facebook profile data).
  • You login with your username and password at the auth server (Facebook in this example) and in the background your client will pass a scope, the application name, etc.
  • The clients gets an authorization code and exchanges that for a token.
  • The token can contain encoded info like your name, session-id and other stuff. It can also contain a refresh token.
  • The client then sends the token to the resource server (which in the example is also Facebook)
  • The resource server validates the token.
  • The client gets access to the data of the resource server.

There is no official method within OAuth2 on how to validate the token. Possible methods are a self containted token like JWT (json web token) or a call from the resource server to the authorization server to validate the code.

Refresh token, concert ticket analogy

In some cases the client can also get a refresh token. It is used to prolong the session.

Compare it with a stamp you get when you want to get out and get in again in a concert. People with a stamp can go in and out, without checking your original ticket.

  • It contains less information than the initial access token.
  • The refresh token can be exchanged from the auth server by another access token (depends on the implementation)

Some more on refresh tokens

Refresh tokens:

  • don’t make the original access token valid again. It just requests a new access token.
  • are only called when the access token is not valid anymore.
  • are valid longer than access tokens, how long exactly depends of the configuration of the authorization server, but it’s way longer than the access token, otherwise there would be no point in having refresh tokens.
  • are not connected to access tokens. They do not "refresh" a given access token.
  • are (initially) provided by OAuth providers alongside access tokens in certain circumstances that vary by the provider. Typically you’ll be able to get a refresh token when using the Authorization Code Grant and requesting an "offline" scope.

Refresh tokens:

  • can expire, although their expiration time is usually much longer than access tokens.

  • can become invalid in other ways (for example if your user revokes your OAuth client app’s access) . In this case all your refresh tokens and access tokens for that provider would be invalidated).

  • can’t be used for read/write access to a user’s information. Only access tokens do this. Refresh tokens are only used to get new access tokens, not read data.

  • You do not provide an access token when using the refresh flow. You just send a valid refresh token and you get an access token back.

  • If your refresh token is invalid and you also don’t have a valid access token for a user, you must send them through an OAuth authorization flow again.

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.