Skip to main content

Add Phone Authentication to Your Java Backend

Wire carrier-grade phone authentication into a Spring Boot API using the official Glide Magical Auth Java SDK. Glide's Magical Auth service selects the strategy (TS43 / Link / Desktop) server-side from the carrier and the caller's user agent — your backend just signs the API calls and forwards them.

1

Install the SDK

Add the Glide Magical Auth Java SDK from Maven Central to your project. The SDK targets Java 11+ (the default HttpExecutor uses java.net.http.HttpClient, no third-party HTTP dependency). This example uses Spring Boot 3, which requires Java 17+.

2

Configure the client as a Spring bean

Build a single thread-safe MagicalAuthClient at startup and inject it into your controllers. The builder accepts only what you actually need — no global state, no static singletons.

3

Create the REST controller

The frontend SDK calls three of your endpoints:

  • /prepare — initialises the auth session. The SDK auto-generates a device-binding code for the Link strategy; you persist it as an HttpOnly cookie and return only the response payload.
  • /process — routes to verifyPhoneNumber() or getPhoneNumber() based on the use case the frontend supplied.
  • /complete — Link-only. Validates the device binding before the client is allowed to call /process.

Branch on result.getAuthenticationStrategy() from the prepare response — not on hardcoded carrier names or User-Agent sniffing. Glide's service has already done that work and tells you the answer.

4

Plain DTO for /process

The SDK's request models are immutable builders. The frontend hands you a flat JSON payload, so define a plain DTO that Spring can deserialise and you map onto the typed builders inside the controller.

5

Anti-fraud signals (SIM swap + device swap)

Both verifyPhoneNumber() and getPhoneNumber() responses include SIM swap and device swap (IMEI-change) fraud signals. Each carries a riskLevel, ageBand, carrierName, and checkedAt when the upstream check succeeded; on failure, isChecked() is false and getReason() explains why.

Use these to gate high-risk operations (large transfers, password resets, account-recovery) — a recent SIM swap is a strong signal of an account-takeover attempt.

6

Device binding (Link strategy)

The Link strategy runs in two modes — mobile-web (the carrier returns the user to a new browser tab on your completion page) and native (Universal Links on iOS, App Links on Android). In both modes, device binding is mandatory: the SDK auto-generates a 64-char binding code during prepare(), hashes it, and sends the hash to Glide. After the carrier redirect lands on your completion page, the SDK validates both halves via complete().

This prevents session-fixation attacks where an attacker tricks a victim into authenticating on the attacker's session.

Read the full Device Binding Security guide →

7

Next steps

Your Java backend is ready.

plugins {
    id 'org.springframework.boot' version '3.2.0'
    id 'io.spring.dependency-management' version '1.1.4'
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'com.glideidentity:glide-be-java-magical-auth:1.0.0'
}
Read-only