Delegated authentication is an arrangement in which one trusted party performs authentication on behalf of another party that relies on the result. In banking and payments, this can mean an issuer, wallet provider, merchant, or other participant authenticates a customer and passes an assurance result to the party making an access or payment decision.
The term is also used in API security to describe delegated authorization, where a resource owner grants an application limited authority to access data or perform actions. The two ideas are related, but they answer different questions: delegated authentication asks who verified the person or device; delegated authorization asks what an application is allowed to do.
For financial institutions, the distinction matters. Delegating an authentication step does not remove the need for risk decisioning, clear responsibility, strong evidence, or controls that match the value and risk of the action.
Delegated authentication works by transferring an authentication result, assertion, or token from a trusted authenticator to a relying party. The relying party then checks whether the result is authentic, current, in scope, and strong enough for the requested action.
A sound design preserves the chain of trust. It should be possible to establish who authenticated the customer, what was authenticated, which action was approved, when the decision was made, and whether the final action stayed inside the approved scope.
In payments, delegated authentication can allow a party other than the payment service provider managing the account or transaction to perform an authentication step. The arrangement is relevant to digital wallets, open banking, card payments, marketplaces, and other journeys involving several regulated or trusted participants.
Delegation can reduce repeated challenges when the authenticating party has an established relationship with the customer and can generate reliable evidence. It can also support a more consistent customer journey across channels. However, delegation must be designed around the payment context, not treated as a blanket transfer of trust.
For each use case, the parties should define the authentication method, assurance level, transaction or action covered, evidence retained, validity period, exception handling, and responsibility if the authentication is inadequate or compromised.
Delegated strong customer authentication, often called delegated SCA, is a payments arrangement in which a regulated party delegates the performance of an SCA step to another provider while retaining defined responsibilities under the applicable regulatory framework.
The EU’s regulatory technical standards for strong customer authentication and common and secure communication establish requirements for secure electronic payments, authentication factors, transaction monitoring, and protection against fraud. Delegation should therefore be assessed against the applicable legal text, supervisory guidance, scheme rules, and contractual allocation of responsibility.
Delegated SCA does not mean that every delegated result automatically satisfies every payment requirement. The payment context, customer interaction, authentication factors, exemptions, transaction binding, audit trail, and liability model all matter. Institutions should obtain legal and compliance advice for their specific operating model.
Read Entersekt’s strong customer authentication guidance for background on SCA, authentication factors, and regulatory context.
OAuth is an authorization framework. It allows a client application to obtain limited access to a protected resource, often with the resource owner’s approval. OpenID Connect adds an identity layer on top of OAuth and is commonly used when a client needs an identity assertion as well as delegated access.
In a typical OAuth flow, the authorization server authenticates the resource owner and issues a token to the client. The token expresses authorization. It should not be treated as proof that the client itself is a trusted authenticator for every later transaction.
Security controls such as audience restriction, short token lifetimes, sender-constrained tokens, proof of possession, authorization-code protection, and careful scope design reduce the impact of token theft or misuse. The IETF’s OAuth 2.0 framework and its current OAuth security best practice are useful references for implementation teams.
| Concept | Primary question | Typical output | Where it is used |
|---|---|---|---|
| Delegated authentication | Who verified the subject? | Authentication result or assertion | Payments, digital banking, wallets, high-risk actions |
| Federated authentication | Which identity provider can a service trust? | Identity assertion or session | Single sign-on and cross-domain identity |
| Delegated authorization | What may an application access or do? | Access token or authorization grant | APIs, open banking, connected applications |
The concepts may appear in the same journey. A customer can authenticate with an identity provider, authorize an application through OAuth, and then receive a payment challenge from a separate service. Clear separation of these functions helps teams assign controls and accountability correctly.
Before adopting delegated authentication, assess the complete trust chain rather than the authentication event alone.
Entersekt’s digital account authentication platform applies authentication across channels and use cases, while risk-based authentication explains how context can determine whether to allow, challenge, or block an interaction.
Delegated authentication is one control in a broader fraud decision. It can establish that an approved authenticator verified a customer, but it may not show that the customer understood a deceptive instruction, that a device remains trusted, or that the transaction matches normal behavior.
Financial institutions should combine delegated evidence with transaction monitoring, device intelligence, behavioral analysis, session controls, and post-login monitoring. This matters because fraud can occur after account access has been granted, including through account changes, new beneficiaries, transfers, and authorized push payment scams.
Context-aware authentication helps institutions decide when delegated evidence is enough and when the customer should complete a further verification step. Entersekt connects authentication and risk signals so institutions can apply stronger controls to higher-risk actions while keeping lower-risk journeys efficient.
Delegated authentication means that one trusted organization verifies a customer and another organization accepts that verification for a defined purpose. The receiving organization still needs to validate the evidence, confirm its scope, and assess whether it fits the requested action.
No. Delegated authentication concerns who verified the person, device, or entity. Delegated authorization concerns what an application or service is allowed to access or do. OAuth primarily addresses authorization, while OpenID Connect adds identity information.
Delegated SCA is an arrangement in which one payment-service participant performs an SCA step for another participant under an agreed responsibility and control model. The arrangement must still meet applicable regulatory, scheme, security, evidence, and transaction-binding requirements.
Yes. Delegated authentication can reduce repeated challenges when the authenticator’s evidence is trusted and relevant to the action. Entersekt combines delegated or out-of-band authentication with risk signals so higher-risk events can receive more assurance than routine interactions.
The main risks include compromised authenticators, stolen tokens, replay, weak transaction binding, unclear responsibility, lost context, and excessive trust in a prior login. Controls should address the full delegation chain and continue monitoring risk after authentication.
Relevant standards depend on the use case. Common references include OAuth 2.0, OpenID Connect, FAPI, FIDO2 and WebAuthn, EMV 3-D Secure, and the regulatory technical standards for SCA under PSD2. The applicable requirements should be confirmed for each market and payment flow.
Regulatory obligations vary by jurisdiction, product, and participant role. This entry is educational and does not replace legal, compliance, or security advice.