Authorization and Authentication @ FARFETCH
By
Nelson ParenteView All Posts
Software engineer addicted to solving complex challenges in the simplest ways. There's a 90% chance I'm wearing Nike in my feet every day.
Top Stories
1 - Authorization and Authentication @ FARFETCH2 - Overcoming the Remote Work Challenges3 - Token Exchange: An Open-Source Story
Over time the Farfetch platform evolved and grew, developing every day to ensure that our users have the best experience possible.
From a single customer to having over two million marketplace consumers in 2019, the Farfetch platform started as a monolithic architecture and has evolved into a geo-distributed service-oriented architecture. In this blog article, we will talk about two very important concepts: Authorization and Authentication. These two concepts are essential for the protection of our customers and their data. The aim of this article is to explain what these two concepts are, their differences, their importance and how they are implemented in the Farfetch platform ecosystem.
Even though the concept of Authorization and Authentication may seem similar, they play different roles. In simpler terms, Authentication is the process of verifying oneself, while Authorization is the process of verifying what they have access to. Together, these two concepts acknowledge that the proper user has the right permissions to access a certain resource.
For the Farfetch platform, Authorization and Authentication are core to the security of Public APIs and our customers and partners. The Farfetch ID cluster is responsible for the set of Services that handle the Authorization and Authentication of our users and APIs, ensuring that the best practices and guidelines are correctly implemented to achieve a higher level of security for all the entities that interact every day with the Farfetch Platform.
Authorization
The evolution from a monolithic architecture to a service-oriented architecture consists, in a practical way, of the transition from a single huge application to a set of services that communicate with each other. In front of this massive army of services are our Public APIs. As the name implies, being public means that they are open to the outside, but this does not mean that their access is free for all.
It is of great importance that the access to our Public APIs have a controlled and regulated admittance, to ensure that they are adequately secured and that only applications with the legitimate authorization can use them.
Authorization, according to the Cambridge Dictionary definition, is "the act of giving official permission or approval”. Thus said, Authorization is the process of verifying whether a user has access or not to a specific resource. For example, the process of knowing which access level an employee has, based on its unique employee identifier.
This leads us to OAuth 2.0, a standard for authorizing a client application to access protected resources. OAuth 2.0, as it stands, is an open standard Authorization framework that provides consumers or consuming applications, secure designated access to data via APIs.
This leads us to OAuth 2.0, a standard for authorizing a client application to access protected resources. OAuth 2.0, as it stands, is an open standard Authorization framework that provides consumers or consuming applications, secure designated access to data via APIs.
Before going deeper into the OAuth 2.0 protocol, let’s map some of the OAuth terminologies.
Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Client: The application that wants to access data or perform actions on behalf of the Resource Owner;
Resource Server: The Server responsible for making resources available. Holds them but does not own them.
Authorization Server: The application that knows the Resource Owner, where the Resource Owner already has an account;
Grant Type: The type of information the client expects to receive.
Scope: These are the granular permissions the client wants, such as access to data or to perform actions; These are divided into two main groups: IdentityScopes, aka claims, and Resources;
Client ID: This unique identifier is used to identify the client with the Authorization Server;
Client Secret: This is a secret password that only the client and the Authorization Server know. This allows them to share information privately behind the scenes securely;
Authorization Code: A short-lived temporary code the client gives the Authorization Server in exchange for an Access Token;
Access Token: The key the client will use to communicate with the Resource Server. This is similar to a badge or key card that gives the Client permission to request data or perform actions with the Resource Server on your behalf;
To summarize, while the OAuth protocol solves the authorization matter, it is equally necessary to address the identification process to allow proper user authentication.
Authentication
How complicated should it be to authenticate a user on the Farfetch platform? It shouldn't be too complicated, right? Right. So, in order to authenticate a user, we only need to match the user with its plain text password. This means that each user must have their plain text password set, and we only need to store the password in a single database table and be able to match it with its user. If a user and its password are correctly matched, we guarantee that the authentication is successful. Easy! This is precisely how authentication at the Farfetch Platform was done in the beginning.
However, with the increasing complexity of the platform and the concerns regarding the security of our users, this straightforward process of authentication was not enough.
Currently, to be able to authenticate a user in the Farfetch Platform, this requires at least six tables in the database and a fully segregated and audited infrastructure containing the services responsible for this operation. We will clarify this process below to explain how the Authentication process is implemented at the Farfetch platform nowadays.
Authentication is the "process of identifying an entity”, according to the Cambridge Dictionary definition. An entity can be a user, an application or even a machine. Since OAuth is designed only for Authorization, granting access to data and features from one application to another, OpenID Connect (OIDC) is responsible for the Authentication process.
OpenID Connect is a thin layer that sits on top of OAuth 2.0, adding a login and profile information about the user who is logged in. Establishing a login session is often referred to as Authentication, and information about the person logged in (i.e. the Resource Owner) is called identity.
The OpenID Connect flow looks the same as OAuth. The only differences are that a specific scope OpenID is used and, in the final exchange, the client receives both an Access Token and an ID Token.
An ID Token represents the outcome of an Authentication process. It contains at a bare minimum an identifier for the user; it can include additional information about the user; and details on how the user has been authenticated. It is a specifically formatted string of characters known as a JSON Web Token or JWT.
A Client Application can extract information embedded in the JWT such as your ID, name, when you logged in, and the ID Token expiration. The data inside the ID Token are called claims.
Now that we are aware of some of the OAuth 2.0 and OpenID Connect terminology let’s take a closer look through the OAuth flow.
- The Resource Owner wants to allow the Client Application to access its addresses.
- The Client Application redirects the browser to the Authorization Server and includes with the request the Client ID, Redirect URI, Response Type, and one or more Scopes it needs.
- The Authorization Server verifies who the Resource Owner is, and, if necessary, prompts for a login.
- The Authorization Server redirects back to Client Application using the Redirect URI along with an Authorization Code.
- The Client contacts the Authorization Server directly (not using the Resource Owner’s browser) and securely sends its Client ID, Client Secret, and the Authorization Code.
- The Authorization Server verifies the data and responds with an Access Token.
- The Client can now use the Access Token to send requests to the Resource Server for its addresses.
The correct implementation of the OAuth and OIDC protocols directly contributes to obtaining a higher level of security and control for the Public APIs of the Farfetch Platform, its customers, and partners.
This is a small sample of the responsibilities of the Farfetch ID cluster who focus on ensuring a level of excellence regarding the security of the Farfetch Platform. There are still several challenges addressed daily by the cluster. Among these challenges, the segregation of data geographically in order to be compliant with the countries data policies, and the Personal User Information, protection, and management.
To sum up, Authorization and Authentication may seem similar concepts, but there is a big difference between them. While Authentication will ensure that you are who you say you are, Authorization will guarantee you access to allowed data. They have different roles and responsibilities and are used together to achieve a higher level of security and control of data on the Farfetch Platform.
References:
