Guidance on Logout Flow with Separate Authorization and Authentication Servers

[robisonkarls]

Hey everyone,

I’m trying to sort out the logout flow in a setup where we’ve separated our Authorization and Authentication responsibilities:

AuthorizationServer → our OAuth2 server (Duende IdentityServer)

Holds all client registrations

Responsible for issuing tokens to internal services

AuthenticationServer → our OIDC server (Duende IdentityServer)

Responsible for authenticating users

Federates to external IdPs (e.g., Microsoft Entra, Okta, etc.)

So effectively:

AuthorizationServer = token service

AuthenticationServer = user authentication & federation

My Question

The logout scenario feels confusing:

Logout initiated by Client

AuthorizationServer /endsession

AuthorizationServer /logout

AuthenticationServer /endsession

AuthenticationServer /logout

External IdP /endsession

This seems like a lot of jumps. Since the client registration (and therefore validation of things like post_logout_redirect_uri) lives in the AuthorizationServer, I’m not sure what the proper logout flow should look like.

Should the client start logout at the AuthorizationServer, which then cascades down to the AuthenticationServer (and possibly the external IdP)?

Or should the logout flow begin at the AuthenticationServer, since that’s where the user’s authentication session actually lives?

Is there a recommended pattern for handling this cleanly when Authorization and Authentication servers are separated like this?

Any guidance or best practices here would be much appreciated.

Thanks in advance!

[AndersAbel]

The logout scenario you describe is correct if your client uses OIDC to connect to AuthorizationServer which is then federated with AuthenticationServer which is federated with the external Idp.

This seems like a lot of jumps.

Yes, if you have multiple steps in your trust/federation this is what it will look like.

Is there a recommended pattern for handling this cleanly when Authorization and Authentication servers are separated like this?

It is not a recommended pattern to separate the Authorization and Authentication services. Session management using OpenID Connect is an extension to the OAuth 2.0 protocol, so by using OpenID Connect from your client to an IdentityServer instances you would get authentication with session management and authorization in one solution.

[robisonkarls]

Thank you @AndersAbel