If you are building an app, you will have to tackle setting up access control for it. Access control is the process of granting your users permission to access certain information. What are the different approaches to access control and which approaches are best suited to different use cases?
If you are building an internet-facing application, you will certainly have to tackle setting up access control for it. Access control is the process of granting your users permission to access certain systems, resources or information. This is commonly known as authentication and authorization. What are the different approaches to access control on the web and which approaches are best suited to different use cases? The team over at Ory wrote a primer answering those questions.
A monolithic application, generally speaking, is one that is built as a single unit. These applications tend to be tightly coupled, have a full IT stack including database, client-side user interface, and server dedicated to it and are scaled as a whole.
For server-side monolithic applications (think of those built with WordPress, Ruby on Rails, LaravelPHP), access control to the resources within is usually done by exchanging credentials such as a username and password for a session cookie. The cookie contains some information about the user such as their user ID. Unless that cookie is set, the user will not be authenticated and therefore will not be allowed to view the desired resource. Some applications, after the authentication step, can take the extra step of checking whether the user has permission to view the resource. This is known as authorization.
Client-side applications tend to come in two flavors. The first is an application built with Javascript and APIs that runs in the browser. These are referred to as Single Page Apps (SPA). The second would be mobile apps.
The main difference from server side applications is that the data is processed on the client-side (ie. the browser) after being fetched by an API. For an SPA that is running in the browser, using the cookie based authentication discussed before makes sense. For a native mobile app though, the preferred method is to use token-based authorization. A token-based authorization flow often involves: presenting the user with a login form, sending the user submitted credentials to an API, retrieving a token from the API, and having the app store the token locally and using it on subsequent requests.
When people talk about microservice architectures, they are referring to a pattern where software is broken out into relatively small, distinct components, each of which can be designed, developed, and managed independently. This allows for distributed ownership of the application and it means that as your company and its requirements grow, the application can grow along with it.
Related: Microservices 101: Understanding and Leveraging Microservices
In this situation it often makes sense to introduce a Single Sign-On (SSO) service which is responsible for managing users and exchanging usernames and passwords for temporary credentials. An SSO service helps users feel like they are dealing with a single ecosystem even as they interact with multiple distributed applications. This is done by letting users log into multiple services with a single set of credentials.
From a security standpoint this is advantageous because the user doesn’t have to submit a password to each service, making it harder for a hacker to eavesdrop. Instead only the SSO has access to them.
Most services these days are asked to serve more than one client. Think of how you can access Netflix on your smart TV, your Roku device, through your Xbox or via your laptop. API access control is best handled by protocols such as OAuth 2.0 and OpenID Connect that use token-based authorization. To learn more about how these technologies are implemented take a look at how OAuth 2.0 and OpenID have been implemented.
