Authentication vs Authorization
Authentication and Authorization are often mixed up. In this article we'll attempt to clarify what each of these terms mean and how they differ. In order to have a secure system, you need both. As a rule of thumb, Authentication is focused on WHO you are and Authorization is focused on WHAT you can do.
Authentication's primary concern is the user's identity. Is the person trying to access the system who they claim to be? Do they have valid credentials? Can they prove it? Are they using a registered device and in a known location? Have they tried to login recently from two different locations?
Modern Authentication platforms or Identity Providers (IDP) like Auth0, Cognito, and Azure AD answer these questions for us. The login screen is the first line of defense: the IDP will require you to login using credentials such as a username and password, a social login (Google, Github, LinkedIn), Passwordless, or Single Sign On. Additionally it may require Multi-factor Authentication such as SMS or an Authenticator app as further proof. The IDP can even go deeper and look at the device you are using, where you are attempting to login from, and your IP address. Once you are authenticated, the IDP will issue an access token (commonly a JWT) that the client app can then use for subsequent calls.
Once you have a valid access token, Authentication is complete. The next question is what are you allowed to do? What can you access? This is where Authorization comes in.
Authorization is concerned with access control - ensuring that users have the right permissions to perform actions on the system. Some applications perform only very coarse-grained authorization, which is why AuthZ is sometimes confused with AuthN. But most real-world applications support different permissions for different types of users, and therefore need to implement some sort of fine-grained authorization.
|0||Verified access token||Ensuring that the caller is sending a valid access token that is signed by a trusted issuer, containing the right audience, and has not expired. This only barely counts as authorization - the application ensures that the user was actually authenticated, but doesn't differentiate between types of users and the permission levels they may have.|
|1||Coarse-grained (scope-based) access control||Requiring that the access token contains one or more scopes, where each scope corresponds to a set of permissions. This can work when you have very broad classes of users - for example, an "admin" is denoted by the "admin" scope. This type of authorization has many limitations, including scope explosion, stale permissions, and lack of resource context, which we describe here.|
|2||Fine-grained access control||Making a call to an external authorization system with a user context, a policy/permission, and a resource context. The authorization system evaluates whether the user has the permission on the resource at this time. This overcomes two big problems with Level 1, which is granularity and staleness. Granularity - you no longer have to embed scopes for EVERY resource in an access token (that's impractical for anything but the simplest systems). Staleness - you no longer have to rely on information that was true 2 hours ago, at the time the access token was minted. You make a real-time authorization decision based on the current state of the world.|
Why you need both
Authentication is the front-door to your system. It helps prevent unwanted actors from getting in unless they have proper credentials. Authorization controls the actions of the user once they get in. It says where they can go, what they can see, and what they can do. If credentials are compromised, Authorization is your next line of defense. It ensures that both well-meaning users and bad actors can't harm the system or compromise your customer's data. A modern Authorization system like Aserto provides the tools to enforce a fine-grained access control model for your users.