Logging into an application is a fundamental, crucial, and yet thankless experience. When it works correctly, most users gloss over its underlying complexity. It is not part of the core product experience but just an expectation.
While designing the authorization stack developers have to weigh security versus convenience in authentication approaches.
The most common kinds of authentication in a web application are:
Basic authentication – send credentials with every request
Token based authentication – send credentials first time to receive a token, then use the token for all subsequent requests
OAuth – it’s complicated
Basic Authentication is exactly what it implies – basic. In this method of authentication, the user credentials have to be passed along with every HTTP request, usually in the format of username:password as a Base64 encoded string. This is passed along in the Authorization header.
In Token Based Authentication the credentials have only to be supplied on login, upon which the auth server provides the client with a token signifying a valid user. All subsequent requests need to be supplied with the token to access protected resources.
OAuth is an open authorization protocol which enables applications to access each other’s data. First let us define three entities that play their part in the OAuth authentication specification:
Client – this is front-end application, the interface that users can directly interact with.
Resource server – the server that contains the data of interest for the client
Authentication server – the server that provides the identity of the client to the resource server.
Now, depending on the use case, the authentication server and the resource server may be the same but it is not necessary to be so. Also there are multiple mechanisms by which an auth server implementing the OAuth specification may grant access to the resource server.
The OAuth grant types are:
Authorization code grant – This is most common use case of OAuth, for example- when applications are asking the user to login via Google/Facebook etc. where Google/Facebook etc. act as the authentication server for the resource server that you (your client application) is trying to access. At the end of the authentication flow, the resource server is granted an authorization token, which it provides to the client. The client then exchanges the authorization token to receive an access token and a refresh token (to renew the access token on expiry).
Implicit grant – This is a simplified authorization flow that can be used by public clients (for example: communication between web applications), where the access token is returned immediately without an extra authorization token exchange step. This has, in time, fallen out of practice and is generally not recommended. It is recommended that public clients use either authorization code grant or client credentials grant instead.
Client credentials grant – This grant type is used when the resource server is also the resource owner. This grant type flow occurs strictly between the resource server (the client in this case) and the authorization server and there is no participation of the end user. The resource server provides its own credentials (the Client ID and Client Secret) to the authorization server, which upon verification returns an access token, hence the name.
Password grant – This grant type flow returns an access token given a username and password. It is typically only used by a service’s own applications and not made available to third parties.
How does authorization server share access token with resource server?
This is not specified in the OAuth 2.0 protocol and has been left as an implementation detail. Generally, JWTs are used which is signed by the authorization server and verifiable by the resource server without querying the authorization server (public key encryption).
Throughout the blog I’ve used authentication and authorization interchangeably several times. Of which the two are not strictly the same, authentication deals identification while authorization deals with permissions, each without the other do not mean much. In this blog I’ve glossed over some of the most popular modes of authentication over the web. I’ll talk more on roles and authorization strategies in my next blog.