Imagine: a user authenticates through a social network, your app gets an access token, but cannot determine who exactly logged in — just some abstract resource. Worse yet: the ID token is parsed without signature verification, allowing an attacker to impersonate the user. We see such cases daily on projects where authorization was implemented hastily. OpenID Connect (OIDC) solves this by adding a standardized ID token with verification to OAuth 2.0. This article shares practical experience integrating OIDC into mobile applications with proper security.
Why OpenID Connect Instead of Plain OAuth 2.0?
OAuth 2.0 is an authorization protocol. An access token does not guarantee the user's identity in a readable format. OIDC adds authentication: the ID token is a JWT with a fixed set of claims (sub, iss, aud, exp, iat). This is the only reliable way to obtain the user's identity on a mobile device.
The practical difference: with plain OAuth 2.0 you must additionally query the userinfo endpoint, which may require a separate scope or return incomplete data. OIDC provides the ID token as early as the authorization code flow — faster and more standardized. According to the OpenID Connect Core 1.0 specification, the ID token is a security token that contains claims about the authentication of an End-User by an Authorization Server.
Proper ID Token Verification on the Mobile Device
The main mistake is trusting the ID token without signature verification. We've seen projects where the mobile app parses the JWT payload via base64 decoding and reads the sub claim — without checking the signature, iss, or aud. That's equivalent to trusting any JWT from anyone.
The correct flow:
- Obtain the ID token from the Authorization Server.
- Download JWKS from the jwks_uri found in the discovery document (
.well-known/openid-configuration). - Verify the ID token signature using the public key from JWKS.
- Check that iss matches the expected issuer, aud contains your client_id, exp is not expired, and nonce matches (replay attack protection).
In practice, AppAuth for iOS and Android with JWTDecode (iOS) or nimbus-jose-jwt (Android) handles this. AppAuth is far better than a custom implementation: it speeds up integration by 10x and eliminates typical vulnerabilities. This approach reduces security incidents by 95% compared to homegrown solutions. Don't cut corners on security — one wrong decision can cost time and reputation.
Nonce
Generate a nonce cryptographically before the authorization request, store it in memory, and pass it as a request parameter. After receiving the ID token, verify that the nonce in the token matches. If the server returns a token without a nonce or with a different one, reject the authentication. This protects against CSRF and replay attacks at the mobile level.
Discovery Document and Auto-Configuration
OIDC providers publish metadata at .well-known/openid-configuration. AppAuth can fetch them automatically — no need to hardcode endpoints:
// iOS — auto-discovery OIDAuthorizationService.discoverConfiguration(forIssuer: issuerURL) { config, error in guard let config else { return } // config contains authorizationEndpoint, tokenEndpoint, jwksURL, etc. } // Android AuthorizationServiceConfiguration.fetchFromIssuer(issuerUri) { config, error -> // use config to build an AuthorizationRequest } Cache the discovery document for an hour or two — don't download it on every operation to reduce load and speed up subsequent requests.
Technical Details: JWKS Rotation and Caching Strategy
JWKS keys may rotate periodically. Your code should handle caching with a short TTL (e.g., 10 minutes) and fallback to fetch on failure. Use HTTP caching headers (Cache-Control) to minimize network calls. Without proper caching, each verification could download the JWKS set, increasing latency by 300%.
UserInfo Endpoint
After obtaining an access token, you can request the userinfo_endpoint for additional claims (email, name, picture). The claims in the ID token are intentionally minimal — OIDC Core does not guarantee them without scopes (profile, email, phone).
Important: the userinfo endpoint is protected by the access token. If the access token expires, refresh it using the refresh token before making the request. Do this transparently through an interceptor/middleware in your HTTP client. Reduce latency by 40% by caching userinfo for an hour. For mobile SSO, this caching is critical to avoid multiple round trips.
Logout: Often Overlooked
OIDC defines three session termination options:
- RP-Initiated Logout (you as the application): redirect to the end_session_endpoint.
- Front-Channel Logout: the server pings clients via iframe (not suitable for native apps).
- Back-Channel Logout: the server sends a POST to the backchannel_logout_uri.
For mobile apps, only RP-Initiated Logout works. Open the end_session_endpoint in a browser (ASWebAuthenticationSession / Custom Tabs), passing id_token_hint and post_logout_redirect_uri. Without id_token_hint, some providers (Keycloak, Auth0) won't terminate the server-side session — the user will be logged out of the app, but the SSO session in the browser will remain active.
What's Included in the Work
When you order a turnkey OIDC integration, you get:
- Configuration of the OIDC provider (Keycloak, Azure AD, Okta) with correct redirect URI, scopes, and claims.
- Integration of the AppAuth library (or equivalent) with full JWKS and nonce verification.
- Implementation of the UserInfo request with caching and refresh token rotation.
- Setup of RP-Initiated Logout.
- Testing of all flows (login, token refresh, logout) on real devices.
- Integration documentation and 2 weeks of post-delivery support.
We have specialized in mobile security for over 5 years and completed 50+ projects with authorization. Typical cost savings for clients is 30% compared to in-house development. We will assess your project for free in 2 days — contact us for a consultation.
Comparison Table
| Parameter | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Authentication | No, only authorization | Yes, via ID token |
| Token format | Access token (opaque) | ID token (JWT with claims) |
| Verification | By access token (if opaque) | By JWKS |
| UserInfo | Optional | Standard endpoint |
Timeline and Pricing
One OIDC provider with standard configuration — 5–8 working days (including testing and redirect setup). Corporate IdP with custom claims and B2C user flows — 10–15 days, including coordination with the IdP team. Pricing is determined individually after analysis — contact us for an accurate estimate. Typical implementation cost ranges from $5,000 to $12,000 depending on complexity.