# Design Patterns
Call run by @alexbabeanu on Jan 25th 2024

## Pattern 1: Provisioning
1. Leads to role explosion
2. Unsure which entitlements users have
3. Resources are black boxes
4. It's easy to roll out - it's RBAC - it's the way we've been working for the past 20+ years

## Pattern 2: Token(OAuth)-based
A user logs into an application, we mint a token that contains all of the authorization data the app will eventually consume. It's a form of JIT provisioning
1. Leads to token bloat
2. Coarse-grained

## Pattern 3: Runtime Authorization (PEP-PDP)
Theoretically the best approach but it requires that applications/resources be onboard. It requires tighter integration.
1. How can we bridge Pattern 2 and Pattern 3?
2. How can we drive adoption of pattern 3?
1. The work done in the other stream (PEP-PDP) isn't enough to drive adoption

## Pattern 3.1

Let's bridge OAuth and Authorization via RAR or other means

## Why do all this?

ZT!

## Recommendations to the world

* Prefer Pattern 3 over Pattern 2 for FGA
* if you have to do Authorization in Pattern 2, consider the IdP/AS as an Application and companion a PDP to it