Attribute-based access control (ABAC) determines API permissions from a user's attributes, the requested resource, and the surrounding business context. The API takes the user ID from the access token's sub claim, retrieves attributes from a database, and evaluates the combination before allowing access. section 7.7
ABAC is more flexible than putting permissions directly in an access token because authorization data can change without updating the authorization server. That flexibility creates risk: rules become complex, implicit assumptions accumulate, and testing and validation become difficult. section 7.7 section 7.8
A project-management API might evaluate access using:
- Job title, geographical location, and project affiliation. section 7.7
- Management scope, such as global, national, regional, state, county, or local access. section 7.7
- Business function and operation type, including separate read and write permissions. section 7.7
Testing an attribute condition
A payments application may permit a user to make payments only after the user's bank account has been verified. An ABAC test should attempt the operation before verification and confirm that the condition is enforced. section 12.4
Figure 7.18 When we apply ABAC, the API determines whether a user has access to the requested resource by checking their combination of attributes in the database.
Use the figure to trace how the API combines a user's stored attributes with the requested resource when deciding access. section 7.7
