OAuth

OAuth is an open standard for delegated authorization. It allows a person to give one application permission to access specific data or functions in their account at another service, without handing over their password. The service issues the application a token, a string that stands for the permission granted, and the application presents that token with each request. The version in general use is OAuth 2.0, published by the Internet Engineering Task Force in 2012.

In financial services OAuth is the mechanism behind most secure connections between banks, payment companies and the applications built on them. It is what happens when a budgeting app asks a customer to log in at their bank and approve access to their transactions, and when a merchant's server proves its identity to a payment provider's API. It is the technical foundation of open banking.

The standard defines four roles. The resource owner is the user. The client is the application asking for access. The authorization server authenticates the user, records what they agree to and issues tokens. The resource server holds the data or performs the action, and accepts requests that carry a valid token. In banking the authorization server and resource server both belong to the bank, and the client is a third-party provider.

The access token is short-lived and limited to a stated scope such as reading balances for one account. A longer-lived refresh token lets the client obtain new access tokens without bringing the user back each time. Because tokens can be limited and withdrawn individually, a customer can cut off one application without changing their password or disturbing any other.

The flow used when a person is present is the authorization code grant. Suppose a customer links their bank account to a personal finance app.

1. The app sends the customer's browser to the bank's authorization page, stating which permissions it wants.
2. The customer logs in at the bank, on the bank's own page, and reviews and approves the request.
3. The bank redirects the browser back to the app with a one-time authorization code.
4. The app's server exchanges the code, together with proof of its own identity, for an access token.
5. The app calls the bank's interface with the token and receives the data.

The app never sees the customer's banking password, and the bank knows exactly which application is calling. An extension called PKCE, now recommended for all clients, ties the code to the application that started the flow so that an intercepted code is useless.

Many payment integrations involve no end user. A merchant's server calling a processor, or a company's treasury system calling its bank, uses the client credentials grant: the client authenticates with its own identifier and secret, or with a certificate, and receives an access token representing itself. This is an alternative to a static API key. The advantage is that the long-lived secret is sent only to the authorization server, while the token used on every request expires quickly and can carry narrow permissions.

Before standard interfaces existed, a data aggregator typically collected the customer's online banking credentials and logged in as the customer, a practice called screen scraping. OAuth replaces this with access that the bank can attribute, limit and revoke. In the European Union and the United Kingdom, the interfaces banks provide under PSD2 use OAuth flows in which the customer is redirected to the bank, the account servicing payment service provider, completes strong customer authentication there and approves the request of an account information provider or a payment initiation service provider. The token then embodies the customer's consent, and consent revocation is carried out by invalidating it.

Plain OAuth 2.0 leaves many choices open, and some permitted options are too weak for high-value data. The OpenID Foundation publishes the Financial-grade API (FAPI) security profile, which fixes the choices: clients authenticate with certificates or signed assertions over mutual TLS, tokens are bound to the client that received them, and requests are signed so they cannot be altered in the browser. National open banking standards in the United Kingdom, Australia and Brazil, among others, are built on FAPI.

OAuth answers the question of what an application may do, not who the user is. Using it alone to log users in has led to security flaws. OpenID Connect, a layer built on OAuth 2.0, adds a signed identity token for that purpose and underlies most sign-in-with features. How the user proves their identity to the authorization server, whether by password, multi-factor authentication or a passkey, is outside the standard.

Most access tokens are bearer tokens: whoever holds one can use it. They must travel only over encrypted connections, be stored carefully and be kept short-lived. Common implementation errors include accepting redirect addresses that were not registered in advance, failing to check the state value that links a response to the request that started it, requesting broader scopes than needed, and leaking tokens into logs.

For customers, the main risk is consent they do not understand or forget about. Good consent management shows clearly what is being shared and for how long, and gives the customer a place, at the bank and at the third party, to review and withdraw access.