Authorization, in information security, is the decision about what an authenticated user, application or device is allowed to do, together with the mechanisms that enforce that decision. Once a system knows who is asking, authorization answers whether that party may view this account, approve this payment, change this limit or call this API. It is applied in every banking app, payment platform, trading system and back-office tool, usually thousands of times a second.
Authorization follows authentication, which proves identity, and is one part of the broader discipline of access control. The word has a different meaning in card payments, where an authorization is the issuer's approval of a specific transaction; that sense is covered at Authorization & Settlement. This entry deals with the security meaning: permissions.
Authorization in plain terms
A hotel key card is a good everyday example. At check-in the receptionist confirms who you are; that is authentication. The card you receive then opens your own room, the gym and the pool, but not other guests' rooms or the kitchen, and it stops working the day you check out; that is authorization.
Computer systems do the same thing with digital permissions. Two people may both log in successfully to the same banking app, yet one can only view balances while the other, a company's finance director, can also approve large payments. The login was the same; what each was authorized to do was not.
How authorization decisions are made
An authorization system has two basic parts. A policy decision point evaluates rules, and a policy enforcement point, built into the application or API gateway, allows or blocks the action. The rules can follow several models:
- Access control lists. Each resource lists who may use it and how, for example read or write.
- Roles. Under role-based access control (RBAC), permissions belong to roles such as cashier, supervisor or auditor, and users inherit them through their roles.
- Attributes. Attribute-based rules combine facts about the user, the data and the context, such as "payments over $50,000 need a second approver who works in treasury".
- Relationships. Some platforms decide by relationship, for example whether a user is an owner, joint holder or authorised signatory on a given account.
Good design follows least privilege and default deny: nothing is allowed unless a rule grants it, and each grant is as narrow as the task requires. In payment operations, authorization rules often enforce segregation of duties, such as the maker-checker control in which one person enters a payment and a different person must approve it, or tiered approval limits in corporate banking where larger amounts need more senior signatories.
Delegated authorization, OAuth and open banking
Modern finance often needs one service to act on a customer's behalf at another. Rather than handing over a password, the customer grants limited, revocable permission. OAuth 2.0, published by the IETF as RFC 6749 in October 2012, is the standard framework for this: the customer authenticates directly with the bank, approves a request, and the bank issues the third party an access token that carries specific scopes, such as "read transactions for 90 days", and expires.
Open banking is built on this pattern. Under PSD2 in Europe and the UK's Open Banking standards, a payment service user (PSU) gives consent to an account information service (AIS) to read data or to a payment initiation service (PIS) to start a payment, and the bank's bank API checks the token, its scopes and the consent before responding. The OpenID Foundation's Financial-grade API (FAPI) profiles tighten OAuth for these high-value uses, for instance by binding tokens to the client's certificate under mutual Transport Layer Security (TLS). In the United States the same model underpins financial data access through bank and aggregator APIs.
Authorization also exists on blockchains. A smart contract may reserve functions such as pausing transfers or minting tokens for holders of an admin key, and the security of the whole protocol then depends on how that key is controlled.
Authorization failures
Broken authorization is among the most common and damaging software flaws. "Broken Access Control" ranked first in the OWASP Top 10 web application security risks in its 2021 edition and kept that place in the 2025 edition. Typical failures include:
- Insecure direct object references. An API checks that the user is logged in but not that the account number in the request belongs to them, so changing one digit exposes another customer's data.
- Privilege escalation. A user finds a way to gain administrator rights, for example through a hidden function that never re-checks permissions.
- Over-broad tokens. Third parties receive more scopes or longer-lived tokens than they need, so a single leak exposes far more data.
- Stale permissions. Staff keep rights from previous roles, allowing one person to both create and approve payments.
The consequences range from a data breach to direct theft. After an account takeover, narrow permissions and transaction limits cap what the criminal can do, which is why authorization is a key layer of fraud prevention. Firms test authorization rules through code review, penetration testing and periodic access reviews, and supervisors increasingly ask about them under cybersecurity risk frameworks.