Authorization Flows

When to use Mobile Connect

Use Mobile Connect when: 

• The user is present and can be redirected to their operator for authentication
• You need a familiar, browser-based consent experience
• You are integrating with existing OpenID Connect style journeys
   

This flow has historically been used for BT and EE identity-backed APIs and was previously bundled directly into API specifications. As flows are now separated, scope usage must be explicitly documented.

Supported scope values

High-level flow

• Your application redirects the user to the BT authorization endpoint
• The user authenticates and grants consent
• Your application receives an authorization code
• The code is exchanged for an access token
• The access token is used to call the protected API
• The exact endpoint details are defined in the OpenAPI specification for each product.
   

When to use CIBA

Use CIBA when: 

• You require a server-to-server or headless integration
• The user is not actively present in a browser
• You want to decouple user interaction from API invocation

CIBA is particularly suited to fraud, KYC, and background verification use cases where the consent model is handled separately.

CIBA prerequisites and JWKS requirement

CIBA uses JWT‑based client authentication rather than browser redirects. Partners must host a publicly reachable HTTPS JWKS endpoint so BT can retrieve the public keys required to validate signed authentication requests. Once the application has been created, the JWKS endpoint URL must be provided to your BT account manager so it can be registered against your app configuration. CIBA does not use redirect URIs or front‑end callbacks.

Supported scope values

High-level flow

• Your system initiates authentication via the CIBA backchannel endpoint
• The operator validates the request and user context
• An authentication result is made available asynchronously
• Your system exchanges the result for an access token
• The access token is used to call the protected API