AWS Verified Permissions

AWS
1

Understanding AWS Verified Permissions: Simplifying Authorization in Modern Apps

In the world of secure applications, two terms are often thrown around authentication and authorization. While they may sound similar, they serve very different purposes.

Authentication vs. Authorization

Authentication is about proving who you are. It’s the process of logging in, like entering a password or scanning your fingerprint.
Authorization, on the other hand, is about determining what you’re allowed to do once you’re in. Just because you’re in the system doesn’t mean you can access everything.

Think of it like this: Authentication gets you into a building while Authorization determines which rooms you can enter.

Authentication Methods & Access Control Models

Before we move on, a quick refresher on how authentication works:

Authentication is all about verifying the identity of a user — in simple terms, it’s answering the question: “Are you really who you say you are?”

There are three common types of authentication methods:

  • Type 1 – Something You Know: This includes things like passwords, PINs, or secret answers to security questions. It’s the most common and traditional form of authentication, but also the most vulnerable if not properly secured.

  • Type 2 – Something You Have: This includes devices or tokens like a mobile phone, hardware security key (e.g., YubiKey), or a one-time passcode (OTP) app like Google Authenticator. It adds a physical factor that makes it harder for attackers to impersonate a user.

  • Type 3 – Something You Are: This refers to biometric data such as fingerprints, facial recognition, voice recognition, or even retina scans. It’s unique to each individual and hard to fake, which makes it a strong form of identity verification

Modern systems often use a combination of these — called multi-factor authentication (MFA) — to ensure a more secure login process.

There are a few popular models used to implement authorization:

  • ABAC (Attribute-Based Access Control): In this model, access is granted based on attributes (or metadata) associated with the user, resource, or environment. For example, a user with the attribute department = “HR” might be allowed to view payroll documents. ABAC is flexible and powerful, but can get complex quickly as conditions grow.

  • GBAC (Group-Based Access Control): Here, permissions are assigned to groups rather than individual users. If a user is part of a specific group (like “Admins” or “Editors”), they inherit the group’s permissions. This approach is easier to manage, especially in larger teams.

  • RBAC (Role-Based Access Control): Roles are defined with specific sets of permissions, and users are assigned roles. For example, a “Manager” role might have permissions to approve requests, while a “Viewer” can only read data. RBAC is widely used because it aligns well with organizational job functions.

These models aren’t mutually exclusive — many modern systems combine them to get the best of all worlds, especially in complex enterprise environments.

What is AWS Verified Permissions?

AWS Verified Permissions is a service that helps developers manage fine-grained authorization in their applications. It decouples permission logic from application code, letting you define access rules using policies — much like how IAM (Identity and Access Management) works for AWS resources.

Policies as Code

The idea of “policy as code” is central here. It means writing policies using a defined syntax, versioning them, and deploying them like any other code.

AWS IAM is a great example — you define access in JSON, attach policies to users/roles, and AWS enforces those rules.

Verified Permissions takes this approach to your custom applications, letting you apply similar logic to your own APIs and services.

Introducing the Cedar Language

To write the policies, AWS Verified Permissions introduces Cedar, a purpose-built language for expressing permissions. Cedar is simple yet powerful, and is used to define what principals (users, groups, or roles) can perform what actions on which resources, under what conditions.

Here’s a basic example of a Cedar policy:

permit(
    principal == User::"Jack",
    action == "view",
    resource == Document::"Homework"
)

This policy means: allow user “Jack” to perform “view” on document “Homework”.

To better understand lets compare Cedar to existing AWS policies, here’s how a similar permission might look using a standard IAM policy in JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/homework",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/jack"
      }
    }
  ]
}

Setting Up Verified Permissions: Step-by-Step

To start using Verified Permissions, here’s a basic outline of what you need to do:

1. Create a Policy Store

A policy store is a container for your authorization logic. It holds your schema and policies.

2. Define a Schema

The schema is like a blueprint of your app’s authorization model — it defines entities like User, Document, Order, etc., and the relationships between them.

Example:

{
  "entityTypes": {
    "User": {},
    "Document": {
      "relations": {
        "owner": {
          "entityTypes": ["User"]
        }
      }
    }
  }
}

3. Write and Add Policies

Write policies in Cedar based on your schema. Upload them to the policy store either through the AWS console or APIs.

You can write policies for specific users, roles, or even groups using logical conditions.

4. Authorize API Requests with Operation IDs

Each API or operation in your app can be associated with an operation ID. You pass this to Verified Permissions at runtime along with the user and resource context. The service evaluates the policy and gives a decision: allow or deny.

Policy Caching Issue

If you use a custom Lambda authorizer and cache the policy decision, be cautious.

Caching can lead to stale authorization data, especially if a user’s permissions change. Caching works only if the user’s access doesn’t change often. If it does, it’s better to evaluate the policy on every request to avoid unauthorized access or unnecessary blocks.

Making Authorization Easier with Verified Permissions and Cognito

When combined with Amazon Cognito, Verified Permissions becomes even more powerful.

You can use Cognito user groups to enable GBAC (Group-Based Access Control), then write policies that reference those groups to control access.

This means your application doesn’t need to handle complex access logic — it simply asks Verified Permissions: Can this user do this thing? And the answer is either allow or deny, based on your clearly defined policies.

Conclusion: Why Verified Permissions Matters

With AWS Verified Permissions, you can centralize and simplify your app’s authorization logic. It removes the need to hardcode permissions, makes policies auditable and maintainable, and plays well with existing identity systems like Cognito.

In short, it leads to cleaner code, better security, and easier management — and that’s a win for everyone.

References:

[1] Tutorial Workshop

[2] Cedar Language Guide

[3] Authorization with Verified Permissions

[4] AWS Community: Using Verified Permissions with Cognito to control access to API endpoints

[5] A new way to manage Permissions

5 Likes