The world we live in today is undoubtedly and almost wholly cloud-native. Organizations have redefined the way in which they build and run software at the foundational level to fit into this world. The cloud-native world is marred with numerous radical changes like a burst of applications, remote users and devices, dynamically scaling platforms, and the ilk. In such a distributed environment, the way of implementing basic fundamental app requirements like authentication and authorization has dramatically changed.
Before we begin to understand why significant changes to authentication and authorization occurred, let us first see what these two words actually mean.
Authentication vs authorization
The act of determining whether someone or something is who or what they declare to be. It helps you get a grasp on the identity of a thing or a person. Authentication is the process of determining the identity of a security principal and is often referred to as “AuthN”. The four major concepts related to AuthN are users, credentials, groups, and roles.
The act of giving someone permission to do or have something. Authorization usually succeeds authentication and is often referred to as “AuthZ”. It is the process of granting an authenticated principal permission to access resources and perform actions. The two major concepts related to AuthZ are roles and permissions.
AuthN and AuthZ in the cloud native world
Nearly a decade ago, a shift to cloud-based applications occurred.
The cloud’s requirements for authentication:
- You need to be fault tolerant because everybody needs to authenticate so many systems that you cannot afford any downtime.
- You need to scale independent of other applications.
- You need to support delegation, microservices, and some kind of federation – even if you are inside your own organization, you need to have some way to connect to other systems to import the users from there or to access the user data from a different system.
- You need to have a standard to integrate all the systems running with different languages and on different platforms.
- You need to be able to support multi-factor authentication because an existence on the cloud significantly increases the chances of phishing attacks.
With the cloud-native shift, the challenge of authenticating a user’s credentials culminated with authentication standards becoming mainstream. Standards like multi-factor authentication (MFA), single sign-on (SSO), and SAML grew significantly.
So, now the general flow of authentication is as follows:
The user goes to an application and says what feature they want to use and tries to access the application. If the user is not authenticated, the application will redirect the user to the central authentication system. This will then provide a login form with the credentials it requires and will return a token in exchange as well as redirect the user back to the application. Then, the browser can present the token to the application and the application can validate it.
This works quite well for using microservices as you can use the same tokens obtained for login & presented by the browser and pass them internally between your microservices. This helps you use credentials to provide global traceability that includes everything part of the authentication token. You would have different tokens per application and would have the same token within an application. You can use HTTP to communicate within your microservice architecture.
So, in modern systems that are able to scale, authentication is based on central authentication. This means you provide your credentials to a central service & you get a token in return that serves as proof of the validation that the authentication system has done. Then, you present your token to the application and it verifies the token by checking the signature and reading the content.
The cloud’s requirements for authorization:
- You need to have role-based access control to make it manageable.
- You should be able to support fine-grained permissions
- You need to support the independent evolution of your microservices. There should be no tight coupling between them just to provide authorization.
- You need to have a central overview and management because you usually have a massive requirement from your management.
After a user is authenticated by the central authentication provider, the user will have roles and you would do a mapping from the role to the permission a user has. This way you can check what permissions are required to perform specific actions. In microservices, each service can check what permissions are derived from a role and then check if the permissions are in place for operation.
Although ten years took care of standardizing authentication, the same cannot be said for authorization. Authorization policies are still customized for each enterprise and application, which means that it does not scale to support cloud-native architecture. This also means that authorization, in its form today, is entirely inefficient for the heterogenous cloud-native environment.
The goal for authorization is essentially to create standardization – construct consistent rules, tools, and frameworks that all enterprises across the world can implement within their application. Furthermore, unifying authorization is needed across the cloud-native stack as elements of cloud-native development do not exist in independent cocoons. This means that these elements interact and require unified authorization standards between and across them.
With a landscape where everything is running on the cloud, organizations must solve the challenge of standardized authorization, just as they did for the standardization of authentication. This will help them ensure secure sessions and thrive in the cloud-native world.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to email@example.com.