DEV Community: theauthkid

OAuth Scopes Made Sense to Me. Then I Learned About Cedar Policies.

theauthkid — Fri, 16 Oct 2026 07:21:03 +0000

Understanding why modern authorization sometimes needs more than roles, scopes, and permissions.

Working around authentication and identity products has taught me that there’s almost always another layer to understand.

Authentication was relatively straightforward for me.

Who are you?

Then came authorization.

Now that we know who you are, what are you actually allowed to do?

OAuth scopes helped me understand that part.

A token might have permission to read:billing, for example. If it doesn't have that scope, it shouldn't be able to perform that action.

Simple enough.

But then I came across a question that made me realize scopes don't tell the whole story:

What if someone should have access to billing, but only under certain conditions?

Maybe they can access it only during business hours.

Maybe the request needs to come from an approved network.

Maybe the person also needs to belong to a particular group.

Now the authorization question isn't simply:

Can this token read billing data?

It becomes:

Can this particular user perform this particular action on this resource under these particular conditions?

That's the problem that helped me understand why policy-based authorization exists.

And eventually, why Cedar started making sense to me.

First, What Is Cedar?

Cedar is an open-source policy language created by AWS for fine-grained authorization.

The easiest way I found to think about it is this:

Instead of burying every access rule inside application logic, you describe the conditions under which access should be allowed or denied as policies.

A policy engine then evaluates those rules when an access decision needs to be made.

One distinction is important here:

Cedar evaluates the authorization request. It doesn't enforce access itself.

It looks at the request and applicable policies and returns an allow or deny decision. The surrounding system then acts on that decision.

What I find useful about this model is that the access rule becomes much easier to reason about.

Instead of thinking through conditions scattered across different pieces of code, you're answering a structured authorization question.

The Four Parts of an Authorization Decision

One concept made Cedar much easier for me to understand.

An authorization request can be thought about using four pieces:

1. Principal: Who is making the request?

This could be a user, service, workload, or another identity requesting access.

2. Action: What are they trying to do?

For example:

read

update

delete

3. Resource: What are they trying to access?

This could be an invoice, API, document, account, or another protected resource.

4. Context: What else about the request matters?

This is where additional information can become part of the authorization decision, such as the time of the request or where the request is coming from.

Put those four together and the question becomes:

Who can do what, to which resource, and under what conditions?

That framing made policy-based authorization much less abstract for me.

So, Why Aren't OAuth Scopes Enough?

This was probably the most useful distinction for me.

Scopes and audiences already solve important problems.

An audience can indicate which API a token is intended for.

A scope can indicate what the token is allowed to do.

For example:

read:billing

That works when the rule is simply:

This client can read billing information.

But real access requirements can become more specific.

Maybe the actual requirement is:

Allow billing access only for members of the admin group.

Or:

Allow access only during a particular time window.

Or:

Allow access only when the request comes from an approved network.

The scope hasn't changed. It's still:

read:billing

What changed are the conditions under which that permission should be granted.

And that's where relying only on static scopes starts becoming limiting.

What Happens Without a Policy Layer?

Those additional authorization checks still have to live somewhere.

An API gateway might check the IP address.

Middleware might check the time.

Application code might check the user's group.

Individually, every check can make sense.

The problem appears when you try to understand the complete access rule.

Imagine someone asks:

Who can access this API, and under exactly what conditions?

If those conditions are spread across gateways, middleware, and application code, there may not be one obvious place to find the answer.

You have to trace it across the system.

From a product perspective, this is what I find interesting about authorization.

It's not only about whether a system can enforce a rule.

It's also about whether teams can understand the rule being enforced.

That's one of the ideas behind using policies.

Instead of distributing every authorization condition across different pieces of logic, policies provide a way to express those rules more explicitly.

How Cedar Thinks About Allow and Deny

At a basic level, Cedar policies use two important effects:

`permit`

A permit policy describes when an action should be allowed.

`forbid`

A forbid policy describes when an action should explicitly be denied.

Cedar evaluates those policies against the principal, action, resource, and context of the request.

There are three behaviors I found particularly useful to understand.

Access is denied by default

If no applicable policy permits the request, access is denied.

`forbid` takes priority

If an applicable policy permits something but another applicable policy forbids it, the request is denied.

Policies are order-independent

The result doesn't depend on which policy happens to appear first.

You don't need to know the entire Cedar syntax to understand why these behaviors matter.

They make the authorization model more predictable.

Where I Came Across Cedar

I started looking more closely at Cedar through my work around MonoCloud.

MonoCloud uses Cedar for API Access Policies, where policies can be evaluated before an access token is issued.

This was the part that made the difference between scopes and policies much clearer to me.

Think about a client requesting:

read:billing

The scope still describes the permission being requested.

But a policy can evaluate whether that permission should actually be granted under the current conditions.

For simpler rules, policies can be configured using structured fields. More advanced rules can use Cedar directly when additional context needs to be evaluated.

So these two things aren't necessarily competing approaches.

They answer different questions.

Scope:

What permission is being requested?

Policy:

Under these conditions, should that permission actually be granted?

That distinction is what finally made the concept click for me.

A Simple Way to Think About It

If I had to explain the progression simply, I'd put it like this:

Authentication

Who are you?

↓

Basic authorization

What are you allowed to do?

↓

Context-aware authorization

Are you allowed to do this specific thing, to this specific resource, under these specific conditions?

Scopes are still useful.

Roles are still useful.

Permissions are still useful.

Policies become valuable when the answer starts depending on more context.

What I Took Away From Learning About Cedar

Before working around identity products, I mostly thought about authorization in terms of roles and permissions.

Admin can do X.

User can do Y.

This token has this scope.

Those models still matter.

But the more I've learned about authorization, the more I've realized that some of the difficult questions begin after you've established the basic permission.

Can they do it right now?

Can they do it from here?

Can they do it to this resource?

Does another condition change the decision?

That's what made policy-based authorization click for me.

Cedar is one way of expressing those rules in a form that a system can evaluate while keeping the authorization logic explicit and readable.

And for me, learning it from the product side, that was far more useful than simply memorizing another security term.

Why Authentication Is Becoming a Core Product Decision in the Age of AI Agents

theauthkid — Thu, 27 Aug 2026 06:55:51 +0000

Nine months ago, if someone had asked me about OAuth, OIDC, authorization policies, or identity infrastructure, I probably would have smiled, nodded, and quietly changed the subject.

Today, I spend most of my days working around these concepts.

I'm a product marketer at MonoCloud, and while I'm not an engineer, I work closely with people building identity infrastructure for users, APIs, services, and AI agents. The more conversations I have, the more architecture diagrams I stare at, and the more product decisions I unpack, the more convinced I become of one thing:

Authentication is one of the most underestimated challenges in modern SaaS.

Not because it's new.

But because the world it was designed for is disappearing.

The Original Promise of Authentication

For a long time, authentication was relatively straightforward.

A user visited an application.

They entered a username and password.

The system verified their identity.

A session was created.

Access was granted.

The application knew who the user was, and that was usually enough.

For many products, authentication was treated as a solved problem. Teams picked a provider, implemented login, issued tokens, and moved on to building features that felt closer to customer value.

And honestly, that approach made sense.

The internet was primarily human-driven.

Humans logged in.

Humans clicked buttons.

Humans made decisions.

The authentication layer existed mainly to answer one question:
"Who is this user?"

Today, that's no longer sufficient.

Modern SaaS Has Changed the Rules

The systems we build today look very different from the systems authentication was originally designed for.

A modern SaaS product rarely consists of a single user interacting with a single application.

Instead, we have:

AI agents performing actions autonomously
Third-party integrations accessing customer data
APIs communicating with other APIs
Multi-tenant architectures serving thousands of organizations
Distributed services making authorization decisions across environments
Compliance requirements demanding detailed audit trails

Identity is no longer just about users.

It's about everything acting within a system.

And every new actor introduces new questions.

Not just who they are.

But what they're allowed to do.

Authentication Is Not Authorization

One of the biggest lessons I've learned while exploring this space is that authentication and authorization are often discussed together but solve very different problems.

Authentication answers:
Who are you?

Authorization answers:
What are you allowed to do?

The distinction sounds obvious until systems become complex.

A user may be authenticated successfully but still shouldn't have access to sensitive data.

An integration may be trusted but only for specific operations.

A service may be legitimate but should only access resources within a defined scope.

An AI agent may be acting on behalf of a user but shouldn't inherit unlimited permissions simply because the user authenticated earlier.

The moment we move beyond simple login flows, authorization becomes just as important as authentication.

And in many cases, significantly harder.

AI Agents Are Exposing the Limits of Traditional Models

This becomes even more interesting when AI enters the picture.

AI agents don't behave like traditional users.

They're not opening a dashboard once a day and manually completing a workflow.

They're increasingly being designed to:

Execute tasks autonomously
Interact with multiple systems
Access external tools
Perform actions across applications
Make decisions without continuous human intervention

That changes the identity conversation entirely.

Consider a simple question:

If an AI agent performs an action, whose action was it?

The user's?

The application's?

The organization's?

The agent's?

The answer isn't always clear.

And that ambiguity creates new challenges around trust, accountability, and security.

We're beginning to see questions emerge that traditional authentication systems were never designed to answer:

How should permissions be delegated to an AI agent?
What does least privilege mean for a system that needs flexibility to reason and act?
How do we revoke an agent's access while it's actively performing tasks?
How do we audit what an agent actually did with the permissions it received?
How do we prevent privilege escalation across connected systems?

These aren't theoretical discussions anymore.

They're rapidly becoming product requirements.

Why This Matters Beyond Security

It's easy to think of authentication as a security team's concern.

But increasingly, identity decisions affect product strategy, customer trust, and business growth.

Enterprise customers want clear access controls.

Compliance frameworks demand auditability.

Developers expect secure defaults.

Users expect transparency around who can access their data.

And AI-powered experiences require entirely new models of delegation and trust.

At some point, identity stops being a backend implementation detail.
It becomes a product decision.

The organizations that treat it as infrastructure alone may find themselves struggling to adapt as systems become more interconnected and autonomous.

The Shift I'm Seeing

What fascinates me most is that we're entering a period where identity is expanding beyond human users.

We're moving toward a world where applications need to understand:

Human identities
Service identities
API identities
Machine identities
Agent identities

And they need to manage trust relationships between all of them.

The industry is still figuring out what this future should look like.

There are emerging standards.

There are evolving best practices.

There are strong opinions.

But there are still many open questions.

Which makes this one of the most interesting spaces to learn about right now.

Why I'm Writing About This

I'm still early in my journey learning about identity, authentication, authorization, developer infrastructure, and AI systems.

I don't claim to have all the answers.

What I do have is curiosity.

I get to work alongside people building these systems, and every week I find myself discovering concepts that completely change how I think about software, security, and product design.

This blog is my way of documenting that learning process publicly.

Over the coming months, I'll be writing about:

Authentication and authorization fundamentals
Identity for AI agents
OAuth, OIDC, and modern identity standards
Multi-tenant SaaS architecture
Developer experience and platform design
AI infrastructure trends
Product marketing and GTM lessons from technical products

Not as an expert teaching from a pedestal.

But as someone learning in public, asking questions, and sharing insights along the way.

If you're building in identity, AI, developer tools, infrastructure, or SaaS, I'd love to learn from your perspective too.

Because the deeper I go into this space, the more convinced I become that authentication isn't a solved problem.

It's becoming one of the defining challenges of modern software.

Why Auth Is the Most Underrated Problem in Modern SaaS (And Why I'm Writing About It)

theauthkid — Tue, 09 Jun 2026 06:09:30 +0000

Hey, I'm Riya, a product marketer working at MonoCloud. We're building a developer platform that brings together identity for users, APIs, services, and AI agents, so teams don't have to stitch together separate tools as they scale beyond basic auth.
I'm relatively new to this space (about 8-9 months in SaaS PMM), and I'm writing here to learn in public, sharpen my thinking, and connect with people building in auth, AI, and infra.

This first post is part intro, part take. Bear with me:)

We've already seen what happens when agents go wrong.

An AI agent with write access deletes an entire production database. Another exfiltrates customer data because nothing was scoping its permissions. A workflow automation tool acts on behalf of a user, but with way more access than that user ever intended to grant.

These aren't hypotheticals anymore. And every time it happens, the postmortem says the same thing: the auth layer wasn't built for this.
Here's the uncomfortable truth: most teams treat authentication and authorization as a checkbox, not an architecture decision. You pick a library, slap on JWTs, call it done, and move on to shipping features. And for a while, it works fine.

But modern SaaS isn't a single user logging in from a browser anymore. It's:

AI agents acting autonomously on behalf of users
Multi-tenant systems where one misconfigured policy exposes the wrong customer's data
Third-party integrations that each need scoped, revocable access
Audit requirements that make "we just check a session token" not good enough

Auth was designed for humans. We're now handing it to machines.

Why this is also an AI problem

The AI layer makes this harder in ways most people haven't fully processed yet. When a human logs in and does something destructive, there's a decision trail. When an agent does it, because it had the keys and the instructions told it to, the question of who authorized what gets genuinely murky.

Identity for AI agents is an open, unsolved problem. Things like: what does "least privilege" mean for an LLM that needs to reason across data? How do you revoke an agent's access mid-task? How do you audit what an AI actually did with its access? These are questions the industry is actively figuring out, and the answers will shape how SaaS products get built for the next decade.

What I'll be writing about

I'm not a dev, but I work closely with the people building this infrastructure every day. My angle is less "here's the code" and more "here's how to think about this": the tradeoffs, the mistakes teams make, the patterns that actually hold up at scale.
Topics I'll be covering, auth and beyond:

Auth architecture for multi-tenant SaaS
Identity and access for AI agents
How AI products are actually being built under the hood
Infra and platform engineering trends worth paying attention to
Developer experience and what makes or breaks a dev tool
SaaS growth, GTM, and the product decisions behind them
Honest takes on tools, standards (OAuth, OIDC, FIDO2), and where the ecosystem is heading

Basically, things I find genuinely interesting as someone sitting at the intersection of product, infra, and AI. If any of that overlaps with what you're building or thinking about, follow along.