[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Logout(LogoutInputModel model)
{
// build a model so the logged out page knows what to display
var vm = await new AccountHelper(_interaction, _clientStore).BuildLoggedOutViewModelAsync(model.LogoutId);
if (User?.Identity.IsAuthenticated == true)
{
// delete local authentication cookie
await HttpContext.SignOutAsync();
}
return View("LoggedOut", vm);
}
[Route("Logout")]
[HttpGet]
public async Task Logout()
{
try
{
await HttpContext.SignOutAsync();
//var client = new HttpClient();
//var tokenResponse = await HttpContext.GetTokenAsync("access_token");
//client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", tokenResponse);
//var url = _appSettings.IdentityServerUri + "Account/Logout";
//string param = $"LogoutId={tokenResponse}";
////HttpContent content = new StringContent(param, Encoding.UTF8, "application/json");
//var response = client.GetAsync(url+param);
}
catch (Exception e)
{
}
}
@kkallberg I'm not too sure what tech stacks your using but assuming you're using React / Angular / Next or something like that you could have a few options. Although without knowing exactly what your production environment is like some of these may not apply.
I'd say possibly the easiest method would be to bundle a second piece of javascript along with your SPA that runs parallel to your app. This piece would solely be responsible for checking the request URI for a token and redirecting away to the identity server if it doesn't exist. This would allow you to pre-fire the redirect even before your SPA is loaded. Then when you're redirected back, your app will load as normal.
You could also reduce the number of redirects by using silent auth and storing the renewal token in a cookie (Maybe someone else could comment on the security of using this token this way).
Another solution is to do the same above but at a server level. Without knowing what server you're using to serve the SPA it's hard to give any exact instructions but if your spa is served using nginx / apache you could configure your htaccess/.conf files to do the same behavior as above. Check the URL for the token parameter, if it doesn't exist (or a renewal cookie for silent auth doesn't exist), redirect to identity server first. If your server doesn't support either of these technologies, you could achieve the same results using a nginx based reverse proxy or possibly even writing a custom solution for whatever server you're using.
Good luck!
In the development mode, the client Angular application is running on HTTP. After successfully logging
when redirect back to the application it keeps reloading again. This is because of HTTP, however, if I change the Node
application to the HTTPS everything is working. Does anyone know how to allow HTTP
I have setup CORS as well
app.UseCors("CorsPolicy");
And in the client setting the allowed CORS are as below
Having issues with Sliding cookies with identityServer. Lets say we have authentication cookie set to expire on identityserver at 1 hour - sliding = true. A client application that uses IdentityServer has an auth cookie is set to 30 minutes, sliding = true. The client application can slide it's cookie every > 15 minutes keeping the user logged in on the client application. However that does not sync back on identityServer side. After 1 hour the session there is effectively ended regardless of the client's sliding. The client will continue to work until it's cookie expires > 30 minutes if no sliding there happens..
The only time a slide on identityserver seems to happen is when the client cookie expires BEFORE the identityserver cookie. In that case, the client logs back in a again, a call to authorize, slides the identityserver cookie. Maybe thinking about this wrong, but expected that when a client cookie slides, this also calls to identityserver to slide that cookie as well (if > 1/2 the expry time).
.AspNetCore.Identity.Application
cookie. It seems that it will contain all the information inserted into my token as well. So there is multiple questions:Hi All, We are using IdentityServer4 , Cert-manager, Kubernetes setup. When using IdentityServer4 admin page we get this error. "unable to obtain configuration from well-known/openid-configuration". We do not get the same error on other pages but only on Identity4 admin. Anybody has faced same issue?
Hi All,
We identified the root cause. It was because https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
We added this preferredChain: "ISRG Root X1" in Issuer.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-isrgx1
spec:
acme:
email: an@email.com
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Hope it helps to anyone having same problem!!
Regards,
Vishal