OAuth is an open standard/specification for achieving authorization. It works over HTTPS, and anyone can implement the specification. The specification works by validating access tokens, and then authorizes devices, APIs, servers, and so on.

Two versions—namely OAuth 1.0 (https://tools.ietf.org/html/rfc5849) and OAuth 2.0 (https://tools.ietf.org/html/rfc6749)—exist. These versions are not compatible with each other and cannot work together. We will use version 2.0 and it will be referred to as OAuth 2.0, throughout this book.

SAML, released in 2005, is a good fit for the web browser (still). But with modern web and native applications (mobile devices), SAML required a serious overhaul, and that's when OAuth came in. Single Page Applications (SPAs) and native applications are different from traditional server-side web applications. SPAs do AJAX/XHR calls to the APIs that are exposed on the server and does many other operations on the client (browser). API development has also changed, from heavy SOAP-based web services using XML to lightweight REST over HTTP using JSON.

OAuth also enables you, as a developer, to gain access to minimal user data without having to give away a user's password. It is mainly for accessing the APIs (REST) exposed by an application, and is done by delegating the authorization function.

OAuth supports a variety of application types and decouples authentication from authorization.

In simple terms, this is how OAuth works:

1. The app that wants to access resources requests the user to grant authorization.
2. If the user authorizes it, the app is given proof for this agreement.
3. Using this proof, the app goes to the actual server with the APIs and gets a token.
4. Using this token, the app can now ask for resources (APIs) to which the user has given access, while giving the proof.

The preceding steps are depicted in the following diagram:

OAuth was tweaked in such a way by using an access token, apps can get user information in the form of an API. Facebook Connect (an SSO application that allows users to interact with other web applications using Facebook credentials) used this as a mechanism to expose an endpoint (http(s)://<domain>/me) that would return minimal user information. This was never clearly there in OAuth specification, and this provoked Open ID Connect (OIDC), which combined the best parts of OAuth2, Facebook Connect, and SAML 2.0. OIDC brought in a new ID token (id_token), and also a UserInfo endpoint that will provide minimal user attributes. Many of the complexities that SAML had, and many of the shortcomings of OAuth2 were addressed by OIDC.

Going deep, into OAuth and OIDC is not in the scope of this book. I am sure that I have given adequate information, using which you can navigate through the rest of this section.