Authentication

Authentication
Authentication methods
Sessions
Content

Authentication

Authentication and authorization are often used within the same framework, and probably the reason they do get sometimes mixed up. Simply put authentication is the process of verifying someone's identity, or making sure that they are who they say they are. Traditionally done by passing a username and password. The user enters its credentials, the site then compares them against those already in file somewhere. Once authentication's completed, the user authorization process begins.

Authorization on the other hand revolves around user privileges. It defines what a user can do and see. Without it you wouldn't be able to prevent one user from accessing another user's account, or restrict users without an account from accessing features only available to account holders.

Authentication methods

Method	Summary
Basic Auth	Username and password,base64 encoded, no cookies or session id, recommended over Https
Bearer Auth	Token Auth, cookies and session id, base64 encoded, recommended over Https
API keys	Single identifier, solution for some unique cases, less secure than basic:
OAuth 2.0	Most secure auth system, access token, best choice for user accounts and granting permissions, allows scopes Popular OAuth flows Auth code - most common flow Implicit - client retrieve access token Resource Owner password - requires user credentials Client credentials - intended for server-to-server
OpenId Connect	Identity layer on top of OAuth 2.0 protocol for end-user identity with server based authentication. Request auth session data and end-users

Cookie/Session authentication

A session contains data about an authenticated user. When you submit your username/password credentials into a site, a user session is created in memory in the server, and the session id sent to the user's browser; where it'll remain until the session expires, browser's closed, or the user moves onto another page. Any subsequent request to the site are handled by a cookie containing the session id, which the server uses to compare with the server side stored session id to validate a user's session. In a session based auth system, the server creates and stores the session data.

Common authentication methods: password, token authentication and multi-factor authentication

Basic authentication

One of the simplest ways to implement user site authentication, it usually involves for a user to first register passing a unique identifier - username, along with a password. All subsquent user requests will then require for the user to produce its credentials - username and password in order to access those resources. Unlike a session-based authorization where a user submits its username and password just once, a basic authentication scheme is stateless, as a result user credentials are needed with every new request.

Basic authentication flow

1_ An unauthenticated user tries to access protected/secured REST resources. 2_ Server replies with authentication required header to client

Example: Server header response:
>$ WWW-Authenticate: Basic

3_ Client passes a base64 encoded string with username and password within Authorization header

Example: Authorization Basic base64encode(username:password)
>$ Authorization Basic YWRtaW456dGvVzdDeeyms==

It should only be used in a HTTPS environment.

4_ At the end-server, the authorization header gets decoded and the username and password extracted.

Token based authentication

Widely used authentication mechanism in single page applications. A JSON web token is an open standard for transmitting data - a JSON object - between two parties. Unlike basic authorization, data is passed within the headers.

Token authorization flow

1_ User register/ makes a request 2_ Server generates a JWT token and sends it to the client 3_ Client stores it in local storage and includes in the header with every request

Token based authentication scales better than sessions since data is stored in the browser, while sessions make use of server memory.

A JSON Token flow

Sample JSON token auth

SPA - Sending sign-in request and getting the token from server

import axios from 'axios'
import Cookies from 'js-cookie'

const signIn = async (email, password) => {
  try {
    const credentials = await axios.post(
      '/signIn', { email, password }
    )
    Cookies.set('credentials', credentials)
  } catch(error) {
    ...
  }
}

SPA - Sending request for an Auth resource to the server

import axios from 'axios'
import Cookies from 'js-cookie'

const getBooks = (email, password) => {
  try {
    const credentials = Cookies.getJSON(
      'credentials'
    )
    if(!credentials) {...}
    return axios.post('/books', null,
    {
      headers: {
        authorization: credentials.token
      }
    })
  } catch(error) {
    ...
  }
}

OAuth 2.0

OAuth provides secured authorization service. It does not authorize a person but instead another application on behalf of a user access to some of the user services. It involves communication from three different parties: the end user, the auth service provider and the third-party application. One of its main roles is protecting users from exchanging credentials directly with third party application, instead this is done through the OAuth service provider.

For example, if you were to login to your Spotify account to listen to some music, and wanted to login using your Facebook account, then instead of passing your credentials with Spotify; which is never a good idea to do - you do this directly through the service provider, in this case Facebook. What would be shared with the application will be defined and scoped by you during the sign on request.

OAuth 2.0 flow implicit

Three separate parties are involved: user, a service provider, and a third-party application. One popular auth flow is the one where users sign up into a web application using their Facebook or Google account. This flow is useful in cases where user's credentials shouldn't be stored in the client, and recommended for web and mobile applications that do not include any server components.

Steps	Action
01	Third-party application requests access directly from service provider.
02	Service provider acknowledges request, and sends back a token - no access been yet given
03	Third-party app passes the token to the user
04	User passes token directly to service provider during authentication - username/password.
05	Once user is granted access, the service provider returns an access token, including some scoped permissions requested by user.
06	User then sends access token back to the third-party app to continue
07	Third-party app upon receiving token makes another request, but this time passing new access token. All subsequent requests will then be handle without any user intervention.
08	User authentication occurs with Open ID Connect: Service provider/API sends back a set of credentials to third party app. These credentials should include a unique identifier and a client secret

Checkout the Google developers OAuth 2 playground tool