Logout implementation architecture

[madurangasiriwardena]

Purpose

Now that SSO establishes and reuses sessions (#3672), we need to be able to end them. This thread covers implementing logout end to end, across the two entry points that have to converge on the same machinery:

• RP-initiated logout — OpenID Connect RP-Initiated Logout 1.0 §2: a browser redirect to the OP's end_session_endpoint.
• Native logout — an API-driven session termination.

Both need to resolve the target session, revoke it and its stored context, revoke the refresh tokens bound to it, notify the other applications that shared it, and — on the browser path — confirm with the user and land them somewhere.

The approach: implement it on the flow model. Rather than build logout as a separate hardcoded path in the OAuth2 layer, we are planning to extend the same flow-graph model SSO already uses. Putting logout on the flow model means these are configured per flow instead of hardcoded in the OAuth2 layer — and it keeps the authoring model consistent with login/SSO.

[darshanasbg]

Overall approach looks good.. @ThaminduDilshan FYI.. We need to introduce a new flow type for logout..

@madurangasiriwardena: Lets say there are two different flows with SSO configured. I assume those two gonna be with two SSO circles. Given thats the case, if we follow this approach for logout, can we use one common logout flow to remove the session for the both login flows, or should there be two different logout flows each one linked to removing specific login flow session?

[ThaminduDilshan]

+1 for the logout flow type.

But do we need to maintain per app logout flows? I'm thinking of the possibility of having a single server wide logout flow. We can allow creating multiple logout flows. But only one can be active/ configured just like user onboarding flows.

Session cookie will be the input for the logout flow. The session record already carries its FlowID (the SSO group key) and the participant list, so we can operate on whatever session the inbound cookie resolves to.

[ThaminduDilshan]

One thing to note, If I understood correctly, SSO cookies are per-flow by name (tid_sso_<hash>), but they all land on the same origin, so a single logout flow sees every one of them in the request. So we have to filter by the tid_sso_ prefix, resolve each via GetByHandle, and terminate accordingly.

[madurangasiriwardena]

@ThaminduDilshan, we need to make sure that we are clearing the session of the group that the application belongs to, and not others. So since the logout request sees all the cookies, we cannot rely on the cookie alone to clear the session.

So my idea is that we have to

• attach a logout flow to an application (similar to how it is done for registration and recovery flows)
• identify the application that initiated the flow using the id token hint (for OIDC) and identify the login flow attached to that application. Then terminate the session for that application group (login flow) only.
  • we need to figure out how it is going to work for app native flows.

[ThaminduDilshan]

For app native, we can expect client to pass appid in the initial request similar to current authentication and self registration flows right? But to assure request is sent by the same client, we may need to expect flow secret as well

[ThaminduDilshan]

Two other points worth considering;

1. Logout CSRF: If termination only needs the cookie, any cross-site request can drive-by log the user out. Need to consider whether we need to protect execution of flows for this type with a secret or similar implementation.

2. OIDC spec inputs: The cookie alone identifies the session, but the RP-initiated logout contract also carries post_logout_redirect_uri, state, id_token_hint, client_id, etc needed for the redirect and confirmation UX. We can flaw these into flow execution in the same approach as with how we're handling authorization requests today. But worth taking a note.

[madurangasiriwardena]

Since the flow secret (for app native) or id token hint (for OIDC) is needed to initiate the logout, can we consider CSRF is not a problem?

[ThaminduDilshan]

Id token hint is only for the oauth right? Yeah. We can think like that.
App native requires flow secret. OAuth (redirect based) can only start logout flow internally

[madurangasiriwardena]

Few concerns raised during the implementation phase by @ThaminduDilshan,

• Is an app without a sign-out flow valid? If so,

  • do we need to consider a default sign-out flow (configured in deployment.yaml) attached by default
  • enable flag isn't needed.

• The sign-out confirmation is technically a consent, but currently its used as just a user prompt. Do we need to consider engaging the consent executor to record the decision?

[ThaminduDilshan]

Is an app without a sign-out flow valid? If so,

• do we need to consider a default sign-out flow (configured in deployment.yaml) attached by default
• enable flag isn't needed.

We're using flow.default_auth_flow_handle to configure a default authentication flow in the deployment.yaml [1]. Flow handle is not unique across different flow types. I.e. different flow types can have the same handle.

We can introduce a default signout flow with the same handle and set it by default for the apps

[madurangasiriwardena]

This tracked and implemented with #2036