[pakl]

> Most implementations are focused on oAuth to establish identity, but the test of your application's security begins after authentication. The major portion is authorization i.e., verifying access to operations and data accessed with those operations.

Agreed. Authentication is quite a solved problem, the major focus for our portfolio of B2B companies is on authorization. They spend significant time on designing scopes which reflect and impact their business.

It is surprising that nearly every solution out there aims to handle both authentication and authorization. We choose to strictly separate these and delegate identity to established third parties or our customers[0].

We recently open sourced The Usher[1], our solution to part of the authorization problem. It is a minimalist server that issues access tokens based on roles and permissions looked up in a database (keyed by the identity token’s `sub` claim). Perhaps folks in this thread will find it useful!

0: https://dev.to/dmgt-tech/introducing-the-usher-an-authorizat...

1: https://github.com/DMGT-TECH/the-usher-server

[dwaite]

> It is surprising that nearly every solution out there aims to handle both authentication and authorization. We choose to strictly separate these and delegate identity to established third parties or our customers[0].

It is a trade-off. Both the authentication and authorization process are typically customized to business requirements, and splitting them apart gives more flexibility in customizing them.

However, the expectation is often that these are both represented to the user as part of the same cohesive experience. Independent implementations of authentication and authorization can make this more challenging.

There is also the expectation that an authentication product provide services like registration and account management. Account management often includes controlling any granted delegated authorizations, which mandates additional coupling between the two systems.