Access control and RBAC in API

1) Why API access control

Authorization is the answer to the question "can this actor perform this action on this resource now? ». Errors lead to BOLA/IDOR leaks, escalation of rights and violation of regulatory requirements. The goal is to build a multi-level model: perimeter → service mash → business rules, with explicit policies and checks at the object level.

2) Authorization models: when to choose what

RBAC (Role-Based Access Control) - roles → permissions. Simple, stable, but prone to "role explosion."

ABAC (Attribute-Based) - decision on the attributes of the subject/object/context (country, KYC level, resource owner, risk).
ReBAC (Relationship-Based) - relationship graph (owner, team member, "project manager"); solves complex hierarchies.
Scopes (OAuth) - a contract between the client and the resource server about the "access area" (for example, 'payments: write').
Practice: RBAC for basic matrix, ABAC for context and constraints, ReBAC for complex hierarchies (folders, organizations, limits and podaccounts).

3) Taxonomy of resources and actions

Hierarchies: 'org → project → wallet → transaction'. Inheritance of rights from top to bottom with possible "limiters."

Actions: CRUD + domain-specific ('approve', 'refund', 'settle').
Resource properties: owner, region, status, risk tags (AML/KYC), limits.
Multi-tenancy: all solutions contain 'tenant _ id'; deny-by-default.

4) Architecture: where the decision is made

PEP (Policy Enforcement Point) - verification site: gateway/API-gateway, sidecar mash, service itself.
PDP (Policy Decision Point) - policy engine: centralized (OPA-service, Cedar-engine) or built-in library.
PIP (Policy Information Point) - attribute sources: user/role directory, tenant profile, CCP/risk, resource ownership map.
PAP (Policy Administration Point) - policy versioning, publishing, auditing.

Recommendation: centralized PDP + local solution cache in PEP; complex object checks in the service in the presence of domain invariants.

5) Tokens, stamps and identity

OIDC/OAuth2: 'sub' (subject identifier), 'aud' (target service), 'scope '/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES signature, short 'exp', re-release by refresh. Don't put PII; use'jti 'for revocation/track audit.
mTLS/HMAC: service-to-service and partners; stamps are pulled from the directory by'client _ id '.
Device/Context: IP/ASN, geo, time of day - login to the ABAC solution (for example, prohibit write outside working hours).

6) Object-level authorization (BOLA-first)

Each operation must respond to "is the subject the owner/has the right to this' resource _ id '?."

Ownership check: 'resource. owner_id == subject. id 'or membership in an' org 'with a role.
Filter samples: always overlay 'WHERE resource. tenant_id =:tenant AND...` (row-level security).
For reference operations (ID in path/body) - normalize and validate to business logic.

7) RBAC Design: Roles, Permissions, Sets

Permissions - atomic rights: 'wallet. read`, `wallet. write`, `payment. refund`.
Roles - named permission sets: 'admin', 'support. read`, `cashier`, `fraud. analyst`.

Scopes - external contract for customers (scope→permissions mapping)

• base roles + permission packs,
• ABAC restrictions (country/region/tenant),
• "Just-In-Time access."

8) ABAC/context constraints

Geo/jurisdiction: ban write from prohibited countries (sanctions/regulatory).
Time/risk: 'risk _ score <threshold' for large operations.
ACC/limits: 'kyc _ level> = 2' for pins> X; control of "cooling down" between transactions.
"Trusted devices": require mTLS for partners on dangerous routes.

9) ReBAC and graph of rights

Useful for complex business structures (groups, teams, brands, branches).

Relationships: 'member', 'admin', 'owner', 'viewer'.
Derived rights: 'viewer' of the resource is inherited from 'member' of the project that belongs to 'org'.
Graph storage: a database with a relationship matrix, a specialized service (in the spirit of the Zanzibar approach). Cache'check (subject, relation, object) 'responses.

10) Solution cache and performance

PDP cache at the PEP level (for example, in a gateway) with the key: 'sub' tenant 'resource' action 'policy _ version'.
TTL short (seconds-minutes) + disability by event: role/relationship/tenant change.
Batch checks (bulk authz) for lists: reduce PDP charges.
Measure latency solutions; during degradation - graceful-degradation only for read (never for write/monetary).

11) Policy examples

11. 1 JWT stamps → rough PEP (pseudo-gateway)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Jurisdiction restriction (deny-list policy)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 ReBAC Policy (pseudo)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Policy and Version Management

Policy versioning ('policy _ version') and canary for dangerous changes.
"Dry-run" (dry-run/shadow decisions) - log 'allow/deny' without impact.
Policy and Migration Directory: Who Changed When and Why; mapping to incidents.
Tests for negative scenarios (prohibited cases) - required in CI.

13) Observability and audit

Decision logs: 'trace _ id', 'subject', 'tenant', 'action', 'resource _ id', 'result', 'policy _ version', reason for failure.
Metrics: 'authz _ decision _ latency', 'authz _ denied _ total {action}', share of BOLA attempts, cache hit-rate.
Dashboards: top failures by actions/tenants, trends after policy releases.

14) Safety and sustainability

Deny-by-default: no explicit permission = deny.
Fail-closed: when the PDP is unavailable, critical write → prohibited (or degraded to the "minimum set" of strictly verified roles).
Local "guard-checks" within services for critical invariants (for example, 'tenant '/' owner').
Minimizing hallmarks in JWT; load sensitive attributes via PIP over a secure channel.

15) Specifics of iGaming/Finance

Roles: 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Restrictions: payment transactions depend on 'kyc _ level', limits of responsible payments, AML status/sanctions.
Lock registers: 'org/brand/device/payment _ instrument' - ABAC filters on write.
Audit logs unchanged for KYC/AML/pin actions; storage according to regulatory deadlines.
Partner APIs: mTLS + contract 'scopes' on routes, geo/ASN filters on perimeter.

16) Testing and verification

Negative-matrix: list explicit "forbidden" cases and fix with tests.
Fuzz authorization: substitution of'tenant _ id', 'owner _ id', bypassing filters when paginating/sorting.
PDP load test: Check the latency and behavior of caches at p95/p99.
Policy release: dry-run + canary + auto-test with expected deny/allow.
Incidents: replay requests on the stand with an accurate version of policies.

17) Antipatterns

Rely only on 'scope' without object checks (BOLA).
Mix business logic and rights checks in each handler without a centralized model.
Hardcode roles in UI and trust client solutions.
Absence of'tenant '/'owner 'filters in requests to the database (leaky reads).
There is no cache solution disability when changing roles/relationships.
Long-lived JWTs without recall/rotation.

18) Prod Readiness Checklist

• Resources/activities, hierarchies and multi-tenancy are defined.
• Basic RBAC matrix + ABAC limiters, where needed - ReBAC.
• PDP/PEP are designed; there is a local solution cache and its disability.
• Policies are versioned, negative scenario tests in CI.
• BOLA checks in each write/read to a specific 'resource _ id'.
• JWT with minimal stamps, short 'exp'; audit/recall on 'jti'.
• Metrics/decision logs, dashboards, alerts by deny/latency.
• Fail-closed for critical write; fallback mode is documented.
• Customer documentation: 'scopes', error codes (401/403/404/409), examples.

19) TL; DR

Build BOLA-first authorization: central PDP + solution cache, RBAC as basis, ABAC for context, ReBAC for relationships. All requests are in the context of 'tenant' and a specific 'resource _ id'; deny-by-default, short JWT, object filters in the database. Version and test policies, measure latency/deny, replay incidents. For iGaming - individual roles (KYC/AML/cash register), hard ABAC limiters and unchangeable auditing.