Patterns for authorization in microservices(osohq.com)
osohq.com
Patterns for authorization in microservices
https://www.osohq.com/post/microservices-authorization-patterns
4 comments
Nice. Think of all the work that AWS puts into IAM, all the other services use it for auth.
seems to be a pattern of problems for most microservices
Are you aware of other (non-Zanzibar) implementations of Pattern 3?
Yeah, although mostly variations on that basic premise.
Airbnb Himeji: https://medium.com/airbnb-engineering/himeji-a-scalable-cent... Carta's AuthZ system: https://medium.com/building-carta/authz-cartas-highly-scalab... Slack's architecture is a bit different, but solves some of the same challenges: https://slack.engineering/role-management-at-slack/
I've also talked to a number of teams who just implemented pattern 3 internally with a custom service. Generally they've determined it's worth it to centralize all authorization data (like roles, groups, etc) into one place and perform ALL permission checks there.
There are also some companies building essentially Zanzibar clones, like Auth0, Authzed, Ory Keto, and a few more.
Airbnb Himeji: https://medium.com/airbnb-engineering/himeji-a-scalable-cent... Carta's AuthZ system: https://medium.com/building-carta/authz-cartas-highly-scalab... Slack's architecture is a bit different, but solves some of the same challenges: https://slack.engineering/role-management-at-slack/
I've also talked to a number of teams who just implemented pattern 3 internally with a custom service. Generally they've determined it's worth it to centralize all authorization data (like roles, groups, etc) into one place and perform ALL permission checks there.
There are also some companies building essentially Zanzibar clones, like Auth0, Authzed, Ory Keto, and a few more.