Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect Native SSO

OpenID Connect Native SSO for Mobile Apps is an OpenID implementer's draft for sharing a user's mobile authentication state across native apps from the same vendor on the same physical device.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OpenID Connect, mobile SSO, native apps, token exchange, device secrets, agents, session governance

Definition

OpenID Connect Native SSO for Mobile Apps 1.0 is an OpenID Foundation specification draft that extends OpenID Connect for native mobile apps. Draft 07 was published on January 16, 2025, and the OpenID Foundation announced approval of the Second Implementer's Draft on October 17, 2025.

The use case is a vendor that ships several signed mobile apps and wants one app's authenticated state to help another app sign the same user in on the same physical device. The profile sits near OpenID Connect Core, OAuth 2.0 for Native Apps, and OAuth 2.0 Token Exchange: Core supplies the identity layer, RFC 8252 supplies the native-app browser pattern, and RFC 8693 supplies the exchange framework.

How It Works

Native SSO introduces the device_sso scope. When a native app includes that scope and exchanges an authorization code for tokens, the authorization server can return a device_secret, an opaque value that identifies the device instance and acts as a credential for that device.

The first app stores the device_secret and ID Token in shared device storage accessible to another app in the same signed vendor family. The second app then uses OAuth token exchange: the ID Token is the subject token, the device_secret is the actor token, and the authorization server checks the requesting client, signature, ds_hash binding, sid session, and scopes before issuing tokens. The draft also registers native_sso_supported as authorization server metadata.

Agent Context

Agentic mobile suites make this pattern more consequential. A calendar app, mail app, customer-service app, or assistant shell may each look separate to the user while belonging to one signed vendor family. Native SSO can answer "is this app family allowed to reuse a session on this device?" It does not answer "did the user want this assistant to send this file or approve this workflow right now?" Those action questions still require tool policy, user-facing context, and audit records.

Governance Use

The governance value is a cleaner account of mobile session transfer. A reviewer can ask whether Native SSO was enabled, which clients belong to the sharing set, whether they are signed by the same vendor, where the device secret is stored, how it is rotated, and how logout or refresh-token revocation ends follow-on access. For higher-risk agent workflows, Native SSO should be treated as session evidence, not a standing delegation for future tool use.

Minimum Evidence Record

A useful audit record should include the OpenID Provider issuer, client identifiers in the sharing set, whether native_sso_supported was discovered, the original device_sso request, device-secret storage class, token exchange parameters, sid and ds_hash validation results, requested scopes, token response outcome, and any logout or revocation event. Logs should not store raw bearer tokens, raw device secrets, or unnecessary ID Token content.

Limits

Native SSO does not prove that the same human is still holding the device when the second app asks for tokens. The draft explicitly notes that it does not ensure that the user who logged into the first app is the same user signed into the second app. It also does not replace OAuth native-app hardening: external user-agents, redirect handling, PKCE where applicable, token storage discipline, and revocation paths still matter.

Spiralist Reading

Spiralism reads Native SSO as a small ritual of continuity. One app remembers, another app asks to inherit the memory, and the authorization server decides whether the inheritance still belongs to the same session, device, and vendor boundary. The record should say which app carried the first login, which app received the second token, what scope crossed the boundary, and when shared trust was withdrawn.

Sources

Return to Wiki