Social sign-in logout

By default, when a user signs in through a social sign-in provider, signing out at that provider doesn't end their Ory session. You can change this default behavior by enabling the provider to tell Ory to end the session it created, so a single sign-out at the identity provider ends the Ory session too.

Ory implements OpenID Connect Front-Channel Logout 1.0. The provider loads a logout URL in a hidden iframe on its own sign-out page, and Ory revokes the session that provider created — only that one, so a provider can never end a session another provider issued. The endpoint always answers 204 No Content, whether or not a session was revoked, so no site can use it to probe whether a visitor is signed in.

warning

Front-channel logout depends on third-party cookies, which most browsers now block. It works in Chrome today, and only while third-party cookies remain enabled there. Treat it as a convenience, not as a guarantee that the Ory session ends. Sessions still expire on their own schedule, and you can always revoke them through the session revocation APIs.

Requirements

• The provider must return a sid claim in the ID token. Ory uses it to match the logout notification to the session it created. Providers that don't emit sid can't use front-channel logout.
• The provider must read claims from the ID token. Set claims_source to id_token (the default). The userinfo endpoint doesn't return sid.
• The user's browser must send third-party cookies. See the warning above.

Configuration

Configure the provider in Ory

Set front_channel_logout on the provider.

1. Get the Ory Identities configuration from your project and save it to a file:

   ory get identity-config --project <project-id> --workspace <workspace-id> --format yaml > identity-config.yaml

2. Add front_channel_logout to the provider configuration:

   identity-config.yaml

   selfservice:
     methods:
       oidc:
         enabled: true
         config:
           providers:
             - id: my-okta
               provider: generic
               client_id: ...
               client_secret: ...
               issuer_url: https://example.okta.com
               mapper_url: base64://...
               scope:
                 - openid
                 - email
               front_channel_logout: true

3. Update the Ory Identities configuration:

   ory update identity-config --project <project-id> --workspace <workspace-id> --file identity-config.yaml

Register the logout URL with your provider

Register Ory as a front-channel logout target in your identity provider's client settings:

Setting	Value
frontchannel_logout_uri	https://<your-ory-domain>/self-service/methods/oidc/frontchannel-logout/<provider-id>
frontchannel_logout_session_required	true

Each provider has its own logout URL, ending in that provider's id, the same way each has its own redirect URI. Give every provider the URL carrying its own id: a URL naming a different provider ends nothing.

frontchannel_logout_session_required makes the provider include the sid parameter in the logout request. Without it Ory can't tell which session to end. The exact field names differ per provider — look for "front-channel logout URL" in the client configuration.

Onboarding users who already have an account

When someone signs in through the provider and their email already belongs to an Ory account, Ory asks them to confirm with a credential that account already has, then links the two. The session that confirmation creates belongs to the provider as well, so signing out at the provider ends it.

Linking a provider from account settings

When a signed-in user links the provider from the settings flow, Ory binds the session they are already signed in with, so signing out at the provider ends that session too.

Limitations

• A provider can only end a session that it is bound to: one created by a sign-in through that provider, or one the user linked it to. Every other session is unaffected by the provider's logout.
• Ory revokes the session server-side. The browser keeps its now-invalid session cookie until the next request, which then fails the session check as usual.