Where Is User Authorization Data Stored?
Hiya,
After authentication (authN) comes authorization (authZ); once you know who the user is, you need to know what they can do in your application.
Every different CIAM software product has different authZ complexities it supports. But in this edition of CIAM Weekly, I'll cover common patterns.
Authentication Only
The first pattern is when the CIAM system is only responsible for authentication. Whether using embedded credentials like a password, federation solutions like SAML or OIDC, or 'what you have' options like magic links, the CIAM product authenticates the user, generates an artifact (often a token) with the results, and passes it on to the application.
The application then examines the artifact, which contains a user identifier. In the OIDC world, it's a `sub` claim: https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims , which is immutable and never reassigned.
The application is responsible for mapping the user identifier to whatever authorization framework it uses and for controlling access to functionality and data based on that.
Benefits:
Each application can use an authorization system or framework that is appropriate to their use case or needs.
The CIAM system can be easily swapped out if you can find another that offers the same authentication options.
Authorization logic is business logic and is kept close to application code.
Challenges:
You can get a centralized view of application authentication from the CIAM product, but not a view of the permissions granted in each application.
You're not taking advantage of a robust generalized permission structure that is typically present in the CIAM system.
Embedded CIAM Authorization
With this approach, you fully leverage the CIAM system's authZ system. What that looks like varies based on the CIAM software package, but you can read the docs for your solution and see what is enabled. A common option is RBAC (role based access control) where you assign users roles and the role or roles are delivered as part of the authentication process.
Benefits:
You can leverage whatever your CIAM system provides, possibly resulting in less custom code.
You have a centralized view of permissions and they are tied to the user profile.
Challenges:
Whatever authorization solution your CIAM system provides may not be granular enough or otherwise might fall short of your needs.
Authorization is business logic and may require integration between each application and the CIAM software.
Coarse and Fine Authorization
Another common pattern is to use the CIAM system's authorization for coarse grained authorization while the application has finer grained controls. If your CIAM solution supports RBAC, you can assign users to roles such as `admin`, `writer`, `viewer`. The application which receives those roles after the authentication event can determine what those roles mean in its context.
It can even apply special authorization rules such as 'a writer can write to their own projects, but not to any other ones', bringing in more complex and local authorization rules.
Benefits:
You have a partial centralized view.
Applications can come up with any authorization scheme that meets their needs and aren't reliant on a centralized system.
Challenges:
You have a partial centralized view.
Applications can come up with any authorization scheme that meets their needs and aren't reliant on a centralized system.
If you have N apps, now you have authorization data in N+1 locations.
Externalized Authorization
The final option is to use yet another external system. In this scenario, you have three architectural components:
the CIAM server
the application
the authorization server
The first two are present in any of the previous option, but the latter is new.
You extract the access control rules to a separate server. The CIAM server is responsible for authentication, the application for business logic, and the authorization server for making decisions about whether application actions are allowed. Doing so usually requires the application to make a request to the authorization server.
Benefits:
You have centralized rule sets at the authorization server and should be able to reason about access in a coherent fashion.
You can use mathematically provable rules to enforce access. While this is possible in other solutions, the separate authorization framework makes this more likely.
Having a separate CIAM server you can have all applications rely on for undifferentiated yet critical functionality is helpful and and an authorization server offers similar benefits.
Challenges:
Mo architecture, mo problems. It's another server or service to care and feed.
Calls to the authorization server become embedded in the application.
If the authorization server's rule definitions aren't flexible enough, you're forced to code logic into your application.
Conclusion
Hope you enjoyed this tour of authorization logic location. Which is right for your app?
The correct answer is ‘it depends’ but I’d try to keep it as simple as possible as you build out and improve your application or applications.
Dan