Blazor Web Assembly and Identity Server 4 - identityserver4

I followed this guide to implement some kind of authentication for my Blazor Web Assembly application. I have an Identity Server 4 instance running on some server, it seems to be completely operational.
My problem is that in the guide above, the returnUrl that is passed to identity server is obviously not a local url. By digging into Identity Server's code, I found that it will always fail to login a user if the return url is not local :
public async Task<AuthorizationRequest> GetAuthorizationContextAsync(string returnUrl)
{
var result = await _returnUrlParser.ParseAsync(returnUrl);
if (result != null)
{
_logger.LogTrace("AuthorizationRequest being returned");
}
else
{
_logger.LogTrace("No AuthorizationRequest being returned");
}
return result;
}
In the code above from DefaultIdentityServerInteractionService, ParseAsync() calls IsLocal() which causes result to be null, which in turn, produces the following in my logs:
2020-09-28T19:37:25.932782009Z [2020-09-28T19:37:25.9324455+00:00] [VRB] [] [IdentityServer4.Services.OidcReturnUrlParser] returnUrl is not valid
2020-09-28T19:37:25.932807561Z [2020-09-28T19:37:25.9325314+00:00] [VRB] [] [IdentityServer4.Services.OidcReturnUrlParser] No AuthorizationRequest being returned
2020-09-28T19:37:25.932817324Z [2020-09-28T19:37:25.9325559+00:00] [VRB] [] [IdentityServer4.Services.DefaultIdentityServerInteractionService] No AuthorizationRequest being returned
Could someone point me towards what I'm not understanding here ? Can I provide any more information ?

I'm not sure if your issue is about LocalUrl, it seems that you set it wrong if you followed the guid.
If you are following default settings, its enough to have client config on IDS4 like this:
new Client
{
ClientId = "wasmappauth-client",
ClientName = "Blazor Webassembly App Client",
RequireClientSecret = false,
AllowedGrantTypes = GrantTypes.Code,
RequirePkce = true,
AllowedCorsOrigins = { "http://localhost:5005" },
RedirectUris = { "http://localhost:5005/authentication/login-callback" },
PostLogoutRedirectUris = { "http://localhost:5005/authentication/logout-callback" },
AllowedScopes = {"openid", "profile"},
}
Here is my blog post which I explained same thing but in simpler wording: https://nahidfa.com/posts/blazor-webassembly-authentication-and-authorization-with-identityserver4/
Edit: About check for local URLs, its it by design on IDS4

Related

LogoutRequest has no PostLogoutRedirectUri in it when using React.js app with ... library

I have an Identity Server 4 instance running at https://localhost:5443/ and a client React.js application running at http://localhost:3000/ and making a reference to the oidc-client library in order to establish the communication. I've been following more or less this article.
The way I've configured the client (in-memory) on the Identity Server is as follows:
new Client
{
ClientId = "react-js-implicit-flow",
ClientName = "Some App name",
ClientUri = "http://localhost:3000",
AllowedGrantTypes = GrantTypes.Implicit,
RequireClientSecret = false,
RedirectUris = { "http://localhost:3000/signin-oidc", },
PostLogoutRedirectUris = { "http://localhost:3000/signout-oidc" },
AllowedCorsOrigins = { "http://localhost:3000" },
AllowedScopes = new List<string>
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"weatherapi.read"
},
AllowAccessTokensViaBrowser = true
}
and the way it looks like on the Ract.js app is like this:
In general, everything goes well. I can login and logout from the Identity Server but the issue is that here:
I get no value (it is null) and this stops the Identity server from redirecting me back to the client application right after logout. If I hard code it (http://localhost:3000/signout-oidc) it works. But for some reason it is just not available.
During the logout this is what the Identity Server logs show:
So, no error, no nothing but I still can not navigate back to the client app after logout.
You do not provide an idTokenHint (id token) with your logout request like the following:
const mgr = new Oidc.UserManager(settings);
const signoutUrl = await mgr.createSignoutRequest({id_token_hint: user.id_token});
window.location.href = signOutUrl.url;
//or
await mgr.signoutRedirect({id_token_hint: user.id_token});
//or just
await mgr.signoutRedirect();
//it will try to attach id_token internally
Lack of the token is the reason for Identityserver to skip the post_logout_redirect_url parameter.
Identityserver has to validate the parameter against the client's configuration, but without the token it can't.
What solved the issue for (me thanks to answer by #d_f) was to change something on the client side and more specifically: src/services/userService/signoutRedirect.

Why does Identity Server GetLogoutContextAsync() method always returns null for PostLogoutRedirectUri?

Identity Server is working as expected. I can log user in and log user out. However the PostLogoutRedirectUri property on LogoutRequest object is always coming back as null.
My SPA client configuration:
{
ClientId = "pokemon",
ClientName = "Angular Pokemon Client",
AllowedGrantTypes = GrantTypes.Code,
RequireClientSecret = false,
RedirectUris = { "http://localhost:4200/login" },
PostLogoutRedirectUris = { "http://localhost:4200" },
AllowedCorsOrigins = { "http://localhost:4200" },
AllowOfflineAccess = true,
AllowAccessTokensViaBrowser = true,
AllowRememberConsent = false,
RequireConsent = true,
AllowedScopes =
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"scope1"
}
}
The settings for AccountOptions object are:
public static bool AllowLocalLogin = true;
public static bool AllowRememberLogin = true;
/.../
public static bool ShowLogoutPrompt = false;
public static bool AutomaticRedirectAfterSignOut = true;
Then on the client I am using the oidc-client library. I have the following settings configured:
const settings = {
authority: "https://localhost:5001",
client_id: "pokemon",
redirect_uri: "http://localhost:4200/login",
response_type: "code",
scope:"openid profile scope1",
userStore: new WebStorageStateStore({ store: window.localStorage })
}
I have tried with post_logout_redirect_uri value and without. Same result.
The way I make the logout request is this.mgr.signoutRedirect(). I have also tried with adding this.mgr.signoutRedirect({ id_token_hint: user.id_token }) but got same result.
The first request going out of my client to the IdP has the following URL
https://localhost:5001/connect/endsession?id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6IjhEQTE2MDdBRTE2NzJGODQ3RkU2NkE2MUI2NEFGM0IxIiwidHlwIjoiSldUIn0.eyJuYmYiOjE2MDE1ODMxODQsImV4cCI6MTYwMTU4MzQ4NCwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMSIsImF1ZCI6InBva2Vtb24iLCJpYXQiOjE2MDE1ODMxODQsImF0X2hhc2giOiJRajc0Z1Z6VGc5WUd3OGVhaTlKWDhRIiwic19oYXNoIjoiM1k2NGtROVFsY2d3Q0VUSGpMT1RDQSIsInNpZCI6IkRFQkFERTA1Njg5RTk1RDY0NUQwNUJGOTkyREJCRTBDIiwic3ViIjoiYWxpY2UiLCJhdXRoX3RpbWUiOjE2MDE1ODMxNjIsImlkcCI6ImxvY2FsIiwiYW1yIjpbInB3ZCJdfQ.xpQo3SFT_Pc4LDtXPHWEETkweLmevUQvPj_84EC98s8qy272mb1dIc3rsIxpHvmBy6f4kI3z4CRs0w6fZmLGyWtZCYCcM6RJhKyGIz_epr-s_ZfZ7XE9Fwvy2FWFZ_HL0SgqLyUCwxKyel0GnzgEmHqcgIbKrK-3KAsVVuNKbXfEwCE-HsVv0OPssAmWvqRdN61ZtbIst4LP6TISkTvlP8HNZozlpbVawGjRPeubyImoYCZgPDVBYI3Ml_xtmSRITdIcTT9S8JmGL4sBIzNXW2ChOTuMvcEkix2lmPH1e9orFA2QOdGgeHylv6sza5ukHR6HTIF9ypoMon-ycNBPJw
Then the second request is fired
https://localhost:5001/Account/Logout?logoutId=CfDJ8CU-F4FvYn9IkMAT1M74c9qWz8pFpIUH_9uKhIkfUFRQKmkVvPVyRNSRpMnTTQ2ZjIqEqFONFzQ6334fLzoKrrUoxjfnIEXYONgXLCnB3IL0OGjaQcP2WIeX-u7UAx_7LIs-DRvGiDEsgnrfhveZknsDPPcJvediQ3viec63gA9EGo5g467Hcd_JClsdikFAd3j2daTxAdVvhmzmjW60ghfibOnsERghDz3FuuX0vDMjBo5JsRyFQeM78BNnvHkoMOIunz2m4RpJLHHzApRxz0Dofl3Oa9JsVxISGevK02Be1W0oTp1eUh_Yb2a6rMYmkhR2vUg4_MazHi61NI5Lvg1X2gn8x3HR2SiKO6-BEiNK07Mt1poyky4A31DcIQiJKQ
On the Identity Server provider, looking at the logs, there are no errors or warning. This code then gets executed:
// get context information (client name, post logout redirect URI and iframe for federated signout)
var logout = await _interaction.GetLogoutContextAsync(logoutId);
var vm = new LoggedOutViewModel
{
AutomaticRedirectAfterSignOut = AccountOptions.AutomaticRedirectAfterSignOut,
PostLogoutRedirectUri = logout?.PostLogoutRedirectUri,
ClientName = string.IsNullOrEmpty(logout?.ClientName) ? logout?.ClientId : logout?.ClientName,
SignOutIframeUrl = logout?.SignOutIFrameUrl,
LogoutId = logoutId
};
and logout?.PostLogoutRedirectUri is always returning null. logoutId has a value. Inspecting source code for GetLogoutContextAsync seems to simply take the logoutId and deserialize it in Message object.
When I manually change PostLogoutRedirectUri to http://localhost:4200 it works. Any ideas why it keeps returning null?
In the logout function on the client side, use the following :-
this._userManager.signoutRedirect({'id_token_hint' : this._user.id_token});
where _user is the returned "User" object. Please refer IdentityServer4 logout as the resolution already exists.
Also, go to the identity server log and check if you get a similar log and observe the call to the session endpoint (the ClientId and the "PostLogOutUri" is null apart from other parameters)

IdentityServer4 Discovery Client Error - Issuer Name Does Not Match Authority

I am getting the 'Issuer name does not match authority' error because I have an ssl-terminating load balancer in front of my is4 service (i.e. issuer is https://myurl and authority is http://myurl).
What should I do in this situation? The dns names are identical, it is the s in https which is causing the validation failure!
It is possible for your Issuer and Authority to be different, but it requires changes to configuration of the server and the discovery request.
On your Identity Server's startup method, you can set the issuer:
var identityServerBuilder = services.AddIdentityServer(options =>
{
if (Environment.IsDevelopment())
{
options.IssuerUri = $"http://myurl:5000";
}
else
{
options.IssuerUri = $"https://myurl";
}
})
And then in your discovery document request:
DiscoveryDocumentRequest discoveryDocument = null;
if (Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == EnvironmentName.Development)
{
discoveryDocument = new DiscoveryDocumentRequest()
{
Address = "http://myurl:5000",
Policy = {
RequireHttps = false,
Authority = "http://myurl:5000",
ValidateEndpoints = false
},
};
}
else
{
discoveryDocument = new DiscoveryDocumentRequest()
{
Address = "http://myurl:5000",
Policy = {
RequireHttps = false,
Authority = "https://myurl",
ValidateEndpoints = false
},
};
}
var disco = await httpClient.GetDiscoveryDocumentAsync(discoveryDocument);
Your issuer url is https however authority url is http. Both urls should be exactly same.
Else you can try setting ValidateIssuerName property to false. This property decides if issuer name has to be identical to authority or not. By default it is true -
var discoRequest = new DiscoveryDocumentRequest
{
Address = "authority",
Policy = new DiscoveryPolicy
{
ValidateIssuerName = false,
},
};
answer from mackie1001 on identityserver4 gitter
your load balancer should forward on the original protocol (X-Forwarded-Proto) and you can use that to set the current request scheme to match the incoming request
you'd just need to create a middleware function to do it
Have a read of this: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.0
for reference this is the code i added to startup:-
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedProto
});
many thanks mackie1001!
if using nginx as the load balancer you will probably need this in service configuration...
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
// Only loopback proxies are allowed by default.
// Clear that restriction because forwarders are enabled by explicit
// configuration.
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
});
and then add this middleware before the identity server middleware
app.UseForwardedHeaders();

IdentityServer/OWIN: Client not being redirected to Login page after Logout

I have a new IdP that implements IdentityServer4 (.NET Core). I am using it to provide SSO/Cookie authentication/authorization to an MVC5 client app. Since the client app is not .NET Core, I use the IdentityServer3 and Microsoft.Owin nugets in order to integrate. There aren't tons of examples of mixing .NET Core and .NET together like this, but there are a few and I've done my best to make it work. Here is the configuration source code for each:
IdentityServer4 (.NET Core, based largely on this example):
new Client()
{
ClientId = "myClientId",
ClientName = "My Client",
ClientSecrets =
{
new Secret("secret".Sha256())
},
AllowedGrantTypes = GrantTypes.HybridAndClientCredentials,
Enabled = true,
RedirectUris = { "http://localhost:5002/signin-oidc" },
PostLogoutRedirectUris = { "http://localhost:5002/signout-callback-oidc" },
AllowedScopes =
{
IdentityServerConstants.StandardScopes.OpenId,
}
}
My Client (MVC5):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies"
});
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
Authority = "http://localhost:5000",
ClientId = "myClientId",
RedirectUri = "http://localhost:5002/signin-oidc",
PostLogoutRedirectUri = "http://localhost:5002/signout-callback-oidc",
ResponseType = "code id_token",
SignInAsAuthenticationType = "Cookies",
Scope = "openid",
Notifications = new OpenIdConnectAuthenticationNotifications()
{
AuthorizationCodeReceived = n => {
n.OwinContext.Response.Cookies.Append("stored_id_token", n.ProtocolMessage.IdToken);
return Task.FromResult(0);
},
RedirectToIdentityProvider = n => {
if (n.ProtocolMessage.RequestType == Microsoft.IdentityModel.Protocols.OpenIdConnectRequestType.LogoutRequest)
{
var idTokenHint = n.Request.Cookies["stored_id_token"];
if (idTokenHint != null)
{
n.ProtocolMessage.IdTokenHint = idTokenHint;
var signOutMessageId = n.OwinContext.Environment.GetSignOutMessageId(); // returns NULL!
//var signOutMessageId = n.OwinContext.Request.Query.Get("id"); // same thing as line above
if (signOutMessageId != null)
{
n.ProtocolMessage.State = signOutMessageId;
}
}
}
return Task.FromResult(0);
}
}
});
Logout mostly works ok. The issue I have is with redirecting back to the login page so that the enduser can login again to the client they just logged out of via the link highlighted here:
The RedirectUri is configured correctly on both sides of configuration (IdP and Client), and the hyperlink's href value is set in the View (pictured), but that URL also needs a query param called "state" attached to it so that it knows which application to log back into (eg. http://localhost:5002/signout-callback-oidc?state=123456789 Clicking this link without the "state" param gives you a 404.). The issue I'm having is that I'm unable to get/set this "state" value in "My Client".
From everything I've read, you get it by calling n.OwinContext.Environment.GetSignOutMessageId() which is actually just calling n.OwinContext.Request.Query.Get("id") under the covers, but it always returns null. Any idea why this returns null??
Thank you!

How to enable front-channel or back-channel logout in identityserver4

I'm looking at how to disconnect the user currently logged on the mvc client (e.g. http://localhost:5001), when that user performs logout on identity server's deployment (e.g. http://localhost:5000)
I understand there's an implementation of OAuth2 in identityserver4 that does just that (https://openid.net/specs/openid-connect-backchannel-1_0.html and https://openid.net/specs/openid-connect-frontchannel-1_0.html)
Luckily for me, Brock Allen just pushed a change in the samples less than a day ago: https://github.com/IdentityServer/IdentityServer4.Samples/issues/197
However the sample is either incomplete at this point, or I'm missing something.
on my server, I'm setting the value of FrontChannelLogoutUrl to http://localhost:5001/frontchannello, and I added that piece of code to my mvc client (basically stolen from the sample):
[HttpGet("frontChannello")]
public IActionResult FrontChannelLogout(string sid)
{
if (User.Identity.IsAuthenticated)
{
var currentSid = User.FindFirst("sid")?.Value ?? "";
if (string.Equals(currentSid, sid, StringComparison.Ordinal))
{
//await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
return new SignOutResult(new[] { "Cookies", "oidc" });
}
}
return NoContent();
}
That code never gets called.
So my question is: should I use backchannel or frontchannel; and, how to implement it
The Identity server 4 documentation describes well how front-channel logout should be implemented. Look for the Quickstart 8_AspnetIdentity as it provides most of the code required for the implementation.
Some highlights of the code required in the identity server :
In the AccountController.cs, the Logout function builds a LoggedOutViewModel and returns a LoggedOut view.
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Logout(LogoutInputModel model)
{
// build a model so the logged out page knows what to display
var vm = await BuildLoggedOutViewModelAsync(model.LogoutId);
...
return View("LoggedOut", vm);
}
The SignOutIframeUrl iframe is served in the LoggedOut.cshtml.
#model LoggedOutViewModel
<div class="page-header logged-out">
<small>You are now logged out</small>
...
#if (Model.SignOutIframeUrl != null)
{
<iframe width="0" height="0" class="signout" src="#Model.SignOutIframeUrl"></iframe>
}
</div>
What remains to be done is defining the FrontChannelLogoutUri for your each of your clients. That's normally done in the identity server's config.cs
public static IEnumerable<Client> GetClients()
{
return new List<Client>
{
// resource owner password grant client
new Client
{
ClientId = "js",
ClientName = "JavaScript Client",
AllowedGrantTypes = GrantTypes.Code,
RequirePkce = true,
RequireClientSecret = false,
RedirectUris = { "http://localhost:5003/callback.html" },
PostLogoutRedirectUris = { "http://localhost:5003/index.html" },
FrontChannelLogoutUri = "http://localhost:5003/frontChannello"
Ok pretty simple. In your Logout action on the account controller (in idserver), make sure you display the LoggedOut view, which in turn shows the iFrame that calls the callback on the mvc client. Pretty much what the spec are saying.

Resources