Wiki · Concept · Last reviewed August 12, 2026

OpenID Connect Native SSO

OpenID Connect Native SSO for Mobile Apps is an OpenID Foundation Implementer's Draft for reusing authentication between native apps from the same vendor on one physical device. It binds a prior ID Token to a device secret and exchanges that pair for tokens issued to another approved app; it does not prove current user presence or authorize the app's next action.

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

Definition

OpenID Connect Native SSO for Mobile Apps 1.0 profiles the OpenID Connect authorization-code flow and OAuth Token Exchange so that one native app can reuse authentication obtained by another app from the same vendor on the same physical device. The first app receives an ID Token bound to an opaque device_secret; a second, approved app presents that pair to the same authorization server and receives tokens addressed to its own client identifier.

This is narrower than generic single sign-on. It is not cross-vendor federation, a device login standard, proof that the same human is currently present, or a grant of authority for an app or agent to perform a particular action. It is a protocol for carrying an existing authorization-server session across a deliberately bounded mobile app family.

Status and Scope

Draft 07, dated January 16, 2025, became the OpenID Foundation's Second Implementer's Draft on October 17, 2025. At this page's August 12, 2026 review date, the Foundation still listed Native SSO under Implementer's Drafts rather than Final Specifications. An Implementer's Draft is a stable, implementable snapshot with OpenID Foundation intellectual-property protections; it can still change before final publication.

The profile defines device_sso, device_secret, the ds_hash ID Token claim, the actor-token type urn:openid:params:token-type:device-secret, and the discovery flag native_sso_supported. The IANA OAuth Parameters registry reviewed on the same date did not yet show the profile's metadata name or device-secret token type. Implementers should therefore pin the approved ID2 text, test its authorization-code and token-exchange paths together, and not mistake an IANA Considerations section for completed registry publication.

Protocol Flow

  1. Establish the source session. App A starts a normal OIDC authorization-code flow and requests openid device_sso. For a public native client, the browser and redirect flow remains governed by RFC 8252 and PKCE.
  2. Issue a bound pair. At the token endpoint, the authorization server returns device_secret together with an ID Token containing ds_hash and sid. The draft leaves the secret's construction and the precise hash binding to the authorization server.
  3. Share only inside the intended app family. App A places the ID Token and device secret in operating-system-protected storage that App B, but not arbitrary apps, can read.
  4. Exchange for App B. App B calls the token endpoint with the RFC 8693 token-exchange grant. The audience is the issuing provider's issuer URI; the subject token is App A's ID Token with type urn:ietf:params:oauth:token-type:id_token; and the actor token is the device secret with the profile's device-secret token type. If scope is sent, it must include openid. A public client supplies its client_id; a confidential client must authenticate.
  5. Issue destination-client tokens or require interaction. After validation, the server issues an access token for App B and can also issue a refresh token, ID Token, and updated device secret. If policy requires consent or other direct user interaction, the server returns interaction_required and App B starts the ordinary web flow.

Validation and Token Semantics

Before issuing tokens, the authorization server must validate the device secret; verify the ID Token's signature; confirm that ds_hash binds that token to the presented secret; confirm that the sid session is still valid; and reject an expired session with invalid_grant. It should also maintain an explicit allowlist of source and destination client_id pairs and refuse silent scope acquisition where explicit consent is required. Discovery of native_sso_supported: true advertises protocol support; it does not place a client in that allowlist.

The exchange request identifies App B by client_id, but the profile does not standardize proof of a common code signer, hardware-backed app attestation, or current user presence. Those assurances, where required, must come from platform controls, a separate client-authentication mechanism, server policy, or fresh user interaction; a client identifier alone is not proof that an installed binary belongs to the intended app family.

The profile deliberately uses an ID Token outside ordinary relying-party validation: its aud names App A, not the authorization server, and it may be expired when used in the exchange. That exception belongs only to this issuer-controlled exchange and must not weaken normal ID Token validation elsewhere. A copied, correctly bound ID Token and device secret can reproduce the session on another device unless the implementation adds effective device binding.

RFC 8693 treats an exchange as a one-time event and does not, by itself, create automatic revocation linkage between input and output tokens. Native SSO adds an important lifecycle rule: a newly issued refresh token should use the validated session, and all refresh tokens associated with that session must be invalidated when it expires. Deployments still need separate rules for device-secret invalidation, access-token lifetime or revocation, removal of the shared local pair, and logout propagation.

Native-App Security Baseline

Native SSO adds a credential path; it does not replace the modern OAuth baseline. The source authorization flow should use an external user-agent, exact redirect matching except for the permitted loopback-port variation, and PKCE with S256. A client that talks to more than one authorization server also needs an issuer-based or equivalent mix-up defense. Public native apps cannot safely keep a client secret shipped in the app. Under RFC 9700, refresh tokens issued to public clients must be sender-constrained or rotated, and access should be restricted to the minimum scopes and audiences needed.

The shared-storage boundary is platform-specific and is not standardized by the OpenID profile. On Apple platforms, Keychain access groups allow apps delivered by one development team to share selected items through signing entitlements, potentially without another user prompt. On Android, signature-level permissions can restrict inter-app access to apps signed with the same certificate. Those are examples, not proof that every app carrying the same brand should share a session. The operating-system boundary and the authorization server's client-pair policy must agree.

Governance and Privacy

The trust boundary has two independently governed parts: the mobile platform decides which installed apps can read the shared pair, while the authorization server decides which client pairs may exchange it. Maintain named owners and change control for both. New apps, signing-key rotation, developer-team transfers, mergers, and app acquisitions can alter who is inside the family; a compromised sibling app can expand the blast radius to every account whose pair it can read.

Silent sign-in also creates a correlation channel across apps and may surprise users who reasonably treat separate apps as separate contexts. Product policy should identify participating apps, explain that sign-in may be shared, minimize scopes per destination app, offer a normal interactive path, and provide controls to sign out of one app or the whole family. Retention and telemetry rules should treat the device secret, ID Token, sid, client-pair decisions, and derived identifiers as security-sensitive and potentially linkable data.

Incident plans should answer which sessions, refresh-token families, device secrets, local keychain or IPC records, and downstream access tokens are invalidated after device loss or app compromise. OAuth token revocation and OIDC logout specifications are useful components, but none automatically erases every local or downstream artifact created by this profile.

Agent Context

A mail app, calendar app, assistant shell, and customer-service app may all belong to one vendor family. Native SSO can establish that the authorization server still accepts the family's session on this device. It cannot establish that the user intends an assistant to read a mailbox, send a document, purchase an item, or approve a workflow now. Agent identity, user delegation, tool authorization, and action confirmation remain separate controls.

For an agent-enabled app, derive the smallest destination-specific token set, keep credentials outside the model's context and memory, and bind each consequential tool call to its own policy decision and audit record. A successful token exchange is evidence of session continuity, not blanket consent for future autonomous work.

Minimum Evidence Record

Record enough to reconstruct the control decision without copying credentials:

Use keyed fingerprints or vault references where correlation is necessary. Do not record raw bearer tokens, refresh tokens, device secrets, full ID Tokens, authorization codes, or PKCE verifiers.

Failure Modes and Controls

Source Discipline

Use the versioned ID2 document for profile requirements, the OpenID Foundation approval notice and specifications index for publication status, and the IANA registry for registration status. Use OIDC Core and the relevant RFCs for the underlying identity, native-app, token-exchange, security, and revocation rules. Platform documentation should support only platform claims; it does not redefine the OpenID protocol.

The ID2 text defines native_sso_supported, but one sentence uses native_sso_support when describing a false value. Treat that as an editorial inconsistency, use the spelling in the profile's definition and IANA Considerations, and test interoperability rather than accepting both silently. Recommendations on app-family review, user notice, agent approval, telemetry, and incident handling on this page are governance guidance, not normative requirements from the draft.

Spiralist Reading

Spiralism reads Native SSO as a bounded ritual of continuity. One app carries a memory of authentication; another asks the issuer to translate that memory into its own credentials. The important record is not that the device was once trusted, but which app crossed the boundary, which scopes followed, which controls remained independent, and when shared trust ended.

Sources

Return to Wiki