Logging Out With AspNet.Security.OpenIdConnect.Ser

问题:

I am using Visual Studio 2015 Enterprise and ASP.NET vNext Beta8 to issue and consume JWT tokens as described here.

In our implementation we're storing some client details in Redis at token issuing time and we would like the flush this information when the user logs out.

My question is what is the best practices for logging out with OIDC?

While I could roll my own contoller for this purpose I couldn't help but notice Open ID Connect (OIDC) seems somewhat primed to handle this case. For example OIDC has an OnLogoutEndpoint handler and LogoutEndpointPath settings. But when I call the OIDC logout URI that handler appears to accept any random x-www-form-urlencoded form I throw at it and doesn't in any particular way seem to be demanding the presence of a token.

Any advice on proper OIDC logout practices would be very much appreciated.

回答1:

In AspNet.Security.OpenIdConnect.Server, the logic used for the logout endpoint is left as an exercise.

In this sample, it is implemented using an MVC 6 controller, where you're - of course - free to add custom logic to remove cached details from your Redis server.

[HttpPost("~/connect/logout")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Logout() {
    // When invoked, the logout endpoint might receive an unauthenticated request if the server cookie has expired.
    // When the client application sends an id_token_hint parameter, the corresponding identity can be retrieved using AuthenticateAsync.
    var identity = await HttpContext.Authentication.AuthenticateAsync(OpenIdConnectServerDefaults.AuthenticationScheme);

    // Remove the cached details here. If you need to determine
    // who's the authenticated user, you can use the identity variable.

    // Remove the authentication cookie and return the user to the client application.
    return SignOut("ServerCookie", OpenIdConnectServerDefaults.AuthenticationScheme);
}

You can also do something similar directly from the LogoutEndpoint event. Don't forget to call context.HandleResponse() to make sure the request is not intercepted by another middleware.