In this article we will talk about how to manage machine to machine (M2M) authentication through the OAuth 2.0 authorization protocol. We will try to shed some light on the differences among authorization, authentication, and the authorization delegation mechanism. We will refer to the OpenID Connect 1.0 (OIDC) specification from which we took inspiration for the implementation of authentication methods.
In the next article instead, we will illustrate and describe our implementation of the M2M authentication and authorization mechanism through the Client Credentials component. Moreover, we wrote an article about Service Accounts.
Sooner or later you need to expose data via APIs and you need to make data available for consumption only to designated customers.
Several projects come into play such as login, credentials, tokens, permissions, authorization, authentication, the flow and order in which certain actions must be performed, and so on. Each of these actions has a precise meaning and boundary. So let’s try to clarify a bit.
Authentication and Authorization: what are the differences?
First we explain the difference between authentication and authorization, two terms often used interchangeably, but which actually have two different meanings and functions.
Authentication allows you to verify that the caller is who he claims to be and therefore to verify his identity. This operation is done through the validation of credentials which can be passwords, biometric data, digital signatures and other methods based on the level of security required by the system. Authentication is usually performed before authorization.
Once the user is authenticated, the authorization establishes the resources they can access by assigning user permissions, rules and policies.
Summing up, authentication allows you to verify the identity of the caller, while authorization allows you to determine the resources that the caller can or cannot access.
It is not easy to manage authorization and authentication. Especially if the server that wants to access a third party resource is a different server than the one that owns it.
Fortunately, there are protocols that help you choose and implement the correct flow for your use case. The best known is the OAuth 2.0 protocol which we will discuss below. We will see that OAuth 2.0 is not an exhaustive specification on authentication and authorization mechanisms, but it deals with describing multiple mechanisms for obtaining an authorization token.
RFC 6749: The OAuth 2.0 Authorization Framework
OAuth 2.0 (OAuth) is described in the RFC 6749 specification titled “The OAuth 2.0 Authorization Framework”. On the oauth.net website it is introduced as “OAuth 2.0 is the industry‑standard protocol for authorization”. By reading these contents you might think that this protocol strictly deals with authorization. Nevertheless, OAuth implies that the system that applies the authorization policies and that grants access to resources already exists.
So what does OAuth 2.0 do?
This protocol can be better framed if described as an access delegation protocol. The role of OAuth is to describe how a client can access the protected resources (Resource) of a user (Resource Owner), which reside on a third server (Resource Server), without the client being aware of the Resource Owner’s credentials.