What is API Authorisation?

Back to learning

API authorisation decides what an authenticated caller is allowed to do. API authentication proves identity; authorisation applies policy to a specific resource, function, tenant, and action. A request can be fully authenticated and still be unauthorised.

That distinction matters because many serious API failures are not caused by a missing login. They happen when the API accepts a real token and then trusts the client, the route, or a hidden frontend control instead of checking the server-side permission that actually matters.

Authorisation Binds Identity to the Resource

Object-level checks are the first line of defence for most APIs. A user may be allowed to call GET /orders/{id}, but only for orders that belong to their account, organisation, or delegated role. A partner may be allowed to read a subset of catalogue data, but not wholesale pricing or customer records. A staff user may be allowed to view a case but not export it.

This is where broken object level authorisation appears. The API verifies the token, finds the route, and returns the object without proving the caller has a relationship to that object. Sequential IDs make this easier to notice, but the core problem is not the ID format. The core problem is that the server skipped the resource check.

GraphQL APIs need the same discipline at resolver level. A query can move through related objects in one request, so authorisation has to follow the data relationship rather than stop at the top-level operation.

For GraphQL-specific controls, see what is GraphQL security?. The important point is the same: a valid caller still needs an object, field, tenant, and action check before data leaves the server.

Function, Scope, and Tenant Checks

Function-level authorisation controls what operations a caller can perform. Reading a profile, changing an email address, issuing a refund, exporting data, inviting an administrator, and deleting a record are different decisions. They should not all pass because the user has a valid session.

Scopes and claims help, but they are inputs rather than the whole decision. An OAuth scope such as orders:read can say the token may read orders. It does not prove which orders, which tenant, whether the caller is acting for themselves or a service account, or whether the request is safe in the current context. Claims in a JWT have the same limitation. They need validation and then server-side interpretation.

Tenant checks are non-negotiable in SaaS and partner APIs. Every query, mutation, export, search, and admin action must be constrained to the caller's tenant unless there is an explicit, audited cross-tenant workflow. Background jobs and internal APIs need the same guardrails because mistakes in privileged paths often have a wider blast radius.

Server-Side Enforcement Beats Client Assumptions

The client can improve usability, but it cannot be the enforcement point. Hiding a button, disabling a menu item, filtering IDs in the browser, or relying on a mobile app flow does not stop a direct API request. The server must decide on every protected action.

Good authorisation is usually layered. The gateway or edge can reject obviously invalid tokens, missing scopes, unknown clients, and routes that should never be public. The application still needs object, function, field, and tenant checks close to the data and business operation. If the application owns the business rule, the application has to enforce it.

Default-deny behaviour is important. New routes, fields, and methods should not inherit broad access because nobody wrote a policy yet. In mature teams, policy changes move through the same review and testing path as application code, which makes DevSecOps practices relevant to access control rather than just vulnerability scanning.

Context and Risk Still Matter

Authorisation is not always a static role lookup. A user may normally be allowed to update billing details, but a risky session, unusual device, new country, recent password reset, or suspected credential stuffing event may justify step-up verification or temporary denial. A partner key may be valid, but a sudden change in route mix or response failures may require tighter limits while the team investigates.

Context-aware checks should be explicit and reviewable. Time, network, device, session age, account state, data sensitivity, and request volume can all help refine the decision, but vague risk scoring is hard to audit. Security teams need to know which condition changed the action and whether legitimate workflows were affected.

Caching also needs care. Caching an authorisation decision can reduce latency, especially in distributed systems, but stale permissions can keep access alive after a role change or key revocation. Short cache windows, tenant-aware keys, and clear invalidation paths matter more than squeezing every millisecond from the policy engine.

Evidence for Review and Response

Authorisation logs should explain the decision without leaking sensitive data. Useful records include subject, client, tenant, route, method, object type, action, scope or role, decision, denial category, policy version, response code, and correlation ID. For API incidents, that evidence shows whether the control failed, whether a caller tested boundaries, or whether a legitimate integration needs a policy adjustment.

This is where authorisation connects to broader API security. WAF, bot, rate limiting, schema validation, authentication, and application policy all see different parts of the same request. Peakhour-style controls keep those signals close enough for operators to make a clear decision: allow the action, deny it, challenge it, throttle it, or investigate it with evidence rather than guesswork.