Consider supporting backchannel logout

[kevinchalet]

Confirm you've already contributed to this project or that you sponsor it

• I confirm I'm a sponsor or a contributor

Describe the solution you'd like

Multiple users recently expressed interest for backchannel logout support in OpenIddict.

It shouldn't be terribly complicated to implement, but it requires a new session entity/manager/store.

We also need to determine what the ASP.NET Core/ASP.NET Core Identity story will look like, as we'll need a stable, per-authentication session identifier that isn't reset when the authentication cookie is refreshed: when directly using the cookie handler, a simple GUID/random ID can easily be attached to the AuthenticationProperties bag, but it's a lot more complicated when the sign-in operation is triggered by ASP.NET Core Identity itself.

Note: there's still no plans to implement frontchannel logout support as it has always been a clunky specification and no longer works for cross-domain communication due to the ban of third-party cookies enforced by most browser vendors.

Additional context

https://openid.net/specs/openid-connect-backchannel-1_0.html
https://openid.net/specs/openid-connect-frontchannel-1_0.html
https://openid.net/specs/openid-connect-session-1_0.html

[kevinchalet]

Note: as part of #2174, the logout endpoint exposed by the server stack was renamed to end-session endpoint, which will avoid any confusion with the backchannel logout endpoint we'll need to implement in the client stack if we decide to support this feature.

[laurentAstonIf]

Any news on the subject ?

[kevinchalet]

@laurentAstonIf looking at the upvotes, it seems this feature is high on the list of things OpenIddict users would like to see implemented. I'll probably take a look as part of the 8.0 effort (it can't happen earlier as new models are required, which can only be done in a major version).

Edit: to set expectations, it's worth noting this specification only works for server-side client applications. Neither desktop/mobile nor browser-apps can support backchannel or frontchannel logout.

[laurentAstonIf]

hello

yes my understanding is that you will add a new entry in OpenIddictApplications something like BackChannelUris
which will contains an endpoint we will have to implement in our backend api

When the spa user logout, the logout endpoint is called, we will perform a signout and somewhere openIdidict
will POST information to these BackChannelUris so the api is now informed that this token is revoked

thanks for this update

[kevinchalet]

Hey @laurentAstonIf,

yes my understanding is that you will add a new entry in OpenIddictApplications something like BackChannelUris
which will contains an endpoint we will have to implement in our backend api

Yes. And assuming we also want to support sessions as part of this feature, we'll also need a new "session" entity to track the list of client applications that were accessed during the same authentication session (aka "visited sites").

so the api is now informed that this token is revoked

If you're only interested in knowing whether a token is revoked, you can use OAuth 2.0 introspection: the client application a token was issued (known as a "presenter" in OpenIddict) is allowed to query its status and can get metadata claims in return. If the token was revoked, an active: false introspection response is returned, which can be used by the client to make the user appear "logged out".

[laurentAstonIf]

My understanding with introspection is that it makes a call to the server each time, so it makes a lot of network calls
when your app doesn't host the server and the client.
A bit like when you set UseLocalServer in the AddValidation

I will have to read a bit more about instropection !