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.
How delegated authentication works
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.
- Authentication is initiated. A customer attempts to sign in, authorize a payment, or approve another high-risk action.
- A trusted party verifies the customer. The authenticator may use device identity, biometrics, a security key, a mobile application, transaction signing, or other approved evidence.
- An assurance result is issued. The result records relevant context, such as the subject, authentication method, time, audience, and permitted scope.
- The relying party validates the result. It checks the issuer, signature, audience, expiry, integrity, and any restrictions before accepting the result.
- The institution makes a risk decision. The transaction or session may be approved, challenged again, delayed for review, or declined.
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.
Delegated authentication in payments
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 SCA and PSD2
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.
Delegated authentication and OAuth
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.
Delegated authentication versus federated authentication
| 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.
Benefits and limitations
Potential benefits
- Fewer repeated challenges: A trusted authenticator can reduce unnecessary interruptions when its evidence meets the relying party’s requirements.
- Consistent customer journeys: A common authentication service can support web, mobile, wallet, and payment experiences.
- Specialized assurance: An institution can use a provider with relevant device, biometric, or transaction-signing capabilities.
- Clearer evidence: Structured assertions and audit records can support investigations, disputes, and compliance reviews.
Key limitations
- Trust concentration: A compromised authenticator or integration can affect many relying parties.
- Scope confusion: Authentication of a customer does not automatically approve every later action.
- Responsibility gaps: Contracts and operating procedures must state who monitors risk, handles incidents, and carries liability.
- Context loss: A generic login result may be insufficient for a payment, account change, or other high-risk action.
- Interoperability risk: Different parties may interpret assurance levels, evidence, or regulatory requirements differently.
What financial institutions should assess
Before adopting delegated authentication, assess the complete trust chain rather than the authentication event alone.
- Identity and authority: Is the authenticator authorized to act for the relevant customer and service?
- Authentication strength: Which factors and cryptographic controls support the result?
- Transaction binding: Is the approval linked to the amount, beneficiary, merchant, account, or other material details?
- Risk context: Can the receiving institution evaluate device, behavior, channel, location, and transaction signals?
- Replay resistance: Can an assertion or token be reused outside its intended session, action, or time window?
- Auditability: Can investigators reconstruct who authenticated what, when, and through which channel?
- Resilience: What happens when the authenticator, mobile channel, identity provider, or network is unavailable?
- Privacy and governance: Are data sharing, retention, access, and cross-border processing rules documented?
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.
How delegated authentication relates to fraud prevention
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.
FAQs about delegated authentication
➡️ What is delegated authentication in simple terms?
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.
➡️ Is delegated authentication the same as delegated authorization?
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.
➡️ What is delegated SCA?
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.
➡️ Can delegated authentication reduce customer friction?
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.
➡️ What are the main security risks?
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.
➡️ Which standards are relevant?
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.
Sources and related articles
- EU regulatory technical standards for SCA
- OpenID Financial-grade API Security Profile
- IETF OAuth 2.0 Security Best Current Practice
Regulatory obligations vary by jurisdiction, product, and participant role. This entry is educational and does not replace legal, compliance, or security advice.
