Better understanding/implementation of external application flow

[di1342]

Hello, a couple months back I asked about logging in from an external client and handling the post-login redirect... I have several more questions regarding interaction whose answers I can't find in your documentation (though they may be there and a simple link will suffice). We are using your latest IS version with ASP.NET Core Identity.

• how do I implement a registration flow? this blog has an example, is it the correct way? (In our case, the registration will not be self-guided so will just redirect to public home page on completion.)
• using the login form provided with your .NET Core Identity quick start, why does clicking "cancel" generate an exception? (duende's code comment: "if the user cancels, send a result back into IdentityServer as if they denied the consent (even if this client does not require consent). this will send back an access denied OIDC error response to the client.") Where is it to be handled so it can be treated as a simple cancel rather than a denial?
• how do I change the signout flow to skip duende's placeholders, simply register the oidc event and redirect to our app's public home page?

Thanks for any light you can shed.

[wcabus]

Regarding your first question, on how to implement a registration flow: the blog post you referenced was correct for Duende IdentityServer before v6.3. But since v6.3 onwards, Duende IdentityServer supports the prompt=create query parameter to redirect a user to a registration endpoint if one is configured.

To configure this registration endpoint, you need to set the CreateAccountUrl setting to the correct path while configuring IdentityServer:

builder.Services.AddIdentityServer(options =>
{
    // ...

    // this would be the path to your registration page or controller action:
    options.UserInteraction.CreateAccountUrl = "/path/to/user/registration/endpoint";
})
// ...

[di1342]

Thanks that's a helpful lens though I can't necessarily parse it all. I do see %26prompt%3Dcreate%26 (we aren't using PAR, looks like we'd need our license first). I also see %26suppressed_prompt%3Dcreate at the query tail.
Perhaps this is not the right call to issue

return Results.Challenge(props);

because the redirect_uri parameter is url1.com/signin-oidc? Or is that as expected? At any rate, the next navigation issued by duende as a result is to url1.com/Account/Login...

[di1342]

In case I wasn't explicit enough: the ordered events in the network log are

1. a call to authorize on url2.com (client application)
2. a call to create on url1.com (duende IS)
3. a call to authorize on url1.com
4. the login navigation

[wcabus]

I'm a bit confused why there would be a call to /authorize on the client application's side, unless this is the name of the controller action/razor page/... on the client application's side which initiates the authentication flow.

Here's the exact network log from a local sample application. Whenever you see app.dev.localhost in the domain, that's the client application, and login.dev.localhost is IdentityServer.

This is the network log explained in more detail:

1. I clicked on Register, triggering the /account/register endpoint in the client application. This is a Razor Page with the following code:

[AllowAnonymous]
public class Register : PageModel
{
    public async Task OnGetAsync()
    {
        var props = new AuthenticationProperties
        {
            RedirectUri = "/"
        };
        
        props.SetParameter("prompt", "create");
        await HttpContext.ChallengeAsync(props);
    }
}

2. HttpContext.ChallengeAsync triggers the OIDC authentication handler in ASP.NET Core, which results in a redirect to the /connect/authorize endpoint on IdentityServer. You can't see it in the network log screenshot, but it the URL contains prompt=create among other values in the query parameter.
3. Since Duende IdentityServer sees prompt=create, it redirects me to the configured URL for the account creation page, hosted at /Account/Create. The code I'm using here is our default UI template implementation, so no additional logic has been added here.
4. I fill in the form and submit it, hence the POST action to the same URL. The form is validated and the resulting logic, in this case, triggers a redirect to the provided returnUrl on IdentityServer's side. This is the redirect to the local /connect/authorize/callback endpoint.
5. IdentityServer processes the callback and completes the authorize flow, redirecting you back to the client application.
6. The client application's OIDC callback endpoint /signin-oidc is triggered to complete the authentication process.
7. Finally, the local redirect to "/" occurs.

[di1342]

I thought of the same thing after watching that flow a couple times. We are using minimal api, so our register is just code. That endpoint mapping has .AllowAnonymous() attached to it but the authorize call on the client would suggest that it's being ignored, which is... odd.

[di1342]

OK dug a little more, and noticed that the registration page itself did not have the [AllowAnonymous] attribute on it. This fixed it--the login I was seeing was coming from the create page load, not the client-side call. This is very dumb on my part! but perhaps useful to other people struggling as I have.
My guess now as far as that first authorize call is that it is being triggered by the overall .RequireAuthorization() call attached to MapRazorPages() and then ignored. I see the same flow on a login challenge (also allowing anonymous obviously). Only a guess of course.

[wcabus]

For your second question, why clicking on the "Cancel" action triggers an error response: this is just how we selected to implement the login flow in our sample and template UI. Duende IdentityServer will redirect the user back to the client application with an OIDC error response, and the client can then decide how to deal with this error.

You can always change this behaviour as needed to tailor it to your scenarios. Unfortunately, there is no easy answer to your question "Where is it to be handled so it can be treated as a simple cancel rather than a denial?". While you're performing the OIDC authentication flow, the end result is either:

• You're authenticated and returned back to the client application.
• You're not authenticated so you need to authenticate first. If you now decide to cancel, that's treated as an OIDC error because it disrupts the normal authentication flow. You could however decide by yourself to redirect the user back to the client application.

[di1342]

I understand the choice of flow implementation, and I further understand why you can't tell me how to write try-catch code ;), so let me try to restate my limited understanding for edification: our current flow is to keep front-channel stuff in duende IS in keeping with best practice, so login lands on duende's account/login page. Call that url1.com/account/login, and call the application's emitting page url2.com/index. When I click the cancel button, I do indeed see the error, but I land on url2.com/signin-oidc, which appears to have been set by the RedirectUris property when configuring the Duende.IdentityServer.Models.Client. I'll confess I don't understand the purpose of this property; your code comment states "Specifies allowed URIs to return tokens or authorization codes to" which doesn't clarify much. Am I supposed to replace that with a page like index? implement a signin-oidc endpoint? It's just not very clear why it lands there when canceling, while following my explicit redirect when logging in successfully. (I haven't yet tested the case of a failed-login-count threshold; one limited understanding at a time.)

[wcabus]

When you click on the Login link in your web application, it will return a challenge action and ask the OpenID Connect authentication handler in ASP.NET Core to authenticate the user. Since this is a remote authentication protocol, it needs to do a few things to ensure that everything will work out:

• It redirects you to Duende IdentityServer in this case, to the authorize endpoint.
• If you're need to authenticate, IdentityServer will redirect you locally to the /Account/Login page.
• Let's say that you enter your credentials successfully in this scenario. This will result in a redirect to the authorize/callback endpoint at IdentityServer first, to issue the necessary tokens.
• Next, IdentityServer redirects you back to the client application to complete the OIDC flow. This is where that /signin-oidc path comes into play: this is the default callback URL as configured by ASP.NET Core's OIDC authentication handler.
• The OIDC authentication handler parses the incoming callback request and then hands of the current authentication ticket to the cookie authentication handler to persist the session in a cookie.

Now, when you cancel on the level of IdentityServer, it responds in the same way by redirecting you back to the client application. But it sets an error response instead of the type "access_denied": IdentityServer treats cancellation as the user not granting consent to the application to act on their behalf, resulting in the "access_denied" error.

On the client application side, you can catch this behavior in two different ways.

Configure the AccessDeniedPath

When configuring the OpenID Connect authentication handler, you can also configure where to redirect the user to when they fail to grant permission to authenticate, or in this case, when they cancel authenticating entirely.

builder.Services.AddAuthentication()
    .AddCookie()
    .AddOpenIdConnect(x =>
    {
        // ... settings omitted for brevity

        // Redirect the user to /Home/AccessDenied when they cancel login at IdentityServer
        x.AccessDeniedPath = "/Home/AccessDenied";

        // Or, if you want to redirect them to your home page instead:
        x.AccessDeniedPath = "/";
    });

Handle the OnAccessDenied event

Another way to respond to the access denied scenario, is to handle the event it triggers during the authentication flow.

builder.Services.AddAuthentication()
    .AddCookie()
    .AddOpenIdConnect(x =>
    {
        // ... settings omitted for brevity

        // When the "access_denied" error is returned...
        x.Events.OnAccessDenied = context =>
        {
            // redirect to the root of the web app
            context.Response.Redirect("/");

            // ... and mark this event as handled
            context.HandleResponse();

            return Task.CompletedTask;
        };
    });

[di1342]

These are great options; the first one solves my problem just fine. I wonder though, if AccessDenied comes from something more nefarious than a cancel-button click (password hack attempts or other attack vectors), there's no real way to distinguish, is there?

[wcabus]

Not on the client application side, no. Whenever the OP sends back the "access_denied" error, the OpenIdConnectHandler transforms the error information into the "Access Denied" event. So any additional error information is already gone. However, you should have more data on the side of IdentityServer when it replies with the "access_denied" error.

[di1342]

understood, we will improve logging on the IS side as we get deeper into implementation, thanks.

[wcabus]

And for the third question, "how do I change the signout flow to skip duende's placeholders, simply register the oidc event and redirect to our app's public home page?", I would need to know a bit more on what you're trying to achieve.

• Do you simply want to only sign out from the client application?
• Or do you want to sign out from the client application and Duende IdentityServer without showing any of the additional logout UI?

[wcabus]

If you've based your Duende IdentityServer UI on our template UI, there is a class called LogoutOptions in the Pages/Account/Logout folder, where you can set AutomaticRedirectAfterSignOut = true;. This will trigger a redirect from the "logged out" page, so you might still see it for a brief second, but that is needed to trigger additional front-channel logout actions if necessary.

There also is a property ShowLogoutPrompt in the same class, but you typically don't need to change the value of this property, as long as you're specifying both a valid post_logout_redirect_uri and id_token_hint during the call to the endsession endpoint.

This behavior is standard in ASP.NET Core, when the OIDC authentication handler has been configured to save the tokens in the authentication cookie:

builder.Services.AddAuthentication(x =>
    {
        x.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        x.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie(x =>
    {
        x.Cookie.Name = "myapp.auth";
    })
    .AddOpenIdConnect(x =>
    {
        x.Authority = "https://myidp.com";
        x.ClientId = "my-client-id";
        x.ClientSecret = "my-secret";
        x.ResponseType = "code";
        
        x.Scope.Add("openid");
        x.Scope.Add("profile");
        x.Scope.Add("email");
        x.Scope.Add("offline_access");
        
        x.GetClaimsFromUserInfoEndpoint = true;
        x.SaveTokens = true; // This needs to be true for automatically adding the id_token_hint parameter when signing out
        x.MapInboundClaims = false;
    });

[di1342]

Changing those static values works well here, though I don't understand why you have to load a page to "trigger additional front-channel logout actions if necessary"? Nothing I see in Logout/Index or Logout/LoggedOut (yes those are your unaltered templates thus far) necessitates a web page load that I can see.

[wcabus]

Duende IdentityServer and its UI templates are built to serve as a common starting point. Since one of the features enables front-channel logout, we needed to supply the basics for this feature to work, resulting in triggering front-channel logout URIs when Duende IdentityServer has logged out a user.

This is done by including an <iframe> HTML tag on the LoggedOut page. You can always remove this if you don't need this, and change the behavior of the Logout/LoggedOut logic to fit you scenario's better.

[di1342]

Sorry it has taken me a minute to get back to this last question. What exactly is that <iframe>'s purpose? I tried to remove it and just redirect to the PostLogoutRedirectUri but it didn't work because that is just the client application's signout node. Maybe it's me being dumb again, but I don't understand the flow. Is there clear documentation describing this interaction between client app and IS at signout time?

[wcabus]

The <iframe>'s purpose is to perform front-channel logout in other client applications where the user has signed in into, so that their session in said applications is also ended upon signing out. Again, you do not need to remove this per se if you aren't using front-channel logout.