No nonce verification for code flow?

As far as I understand, nonce stored in the cookie to make sure the authentication response is coming from the same same client which originally initiated the request.

I’m using code flow and it seems like even though nonce cookie does get set, it’s not really used and I successfully get authenticated no matter if I had the nonce cookie or not. Looks like one of the reasons is this line:

https://github.com/aspnet/AspNetKatana/blob/main/src/Microsoft.Owin.Security.OpenIdConnect/OpenIdConnectAuthenticationOptions.cs#L62

By this, if the response has been intercepted somewhere in the middle, an attacker can go and use the auth code without the additional layer of security the nonce provides.

Not sure if this is by design or is a bug?

Below is my config - please pay attention to the DiscardCookieManager that basically discards any cookies the middleware is trying to set:

public void Configuration(IAppBuilder app)
{
    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
    {
        Authority = oidcAuthority,
        ClientId = oidcClientId,
        ClientSecret = oidcClientSecret,
        RedirectUri = applicationUrl + "signin-oidc",
        PostLogoutRedirectUri = applicationUrl,
        Scope = OpenIdConnectScope.OpenIdProfile,
        ResponseType = OpenIdConnectResponseType.Code,
        RedeemCode = true,
        SaveTokens = false,
        AuthenticationMode = AuthenticationMode.Passive,
        CookieManager = new DiscardCookieManager(),
        TokenValidationParameters = new TokenValidationParameters
        {
            AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType,
            NameClaimType = oidcNameClaimType
        },
        Notifications = new OpenIdConnectAuthenticationNotifications
        {
            AuthenticationFailed = OnAuthenticationFailed,
            SecurityTokenValidated = OnSecurityTokenValidated
        }
    });
}

class DiscardCookieManager : ICookieManager
{
    public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { }
    public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { }
    public string GetRequestCookie(IOwinContext context, string key) => "";
}

private Task OnAuthenticationFailed(AuthenticationFailedNotification<OpenIdConnectMessage, OpenIdConnectAuthenticationOptions> n)
{
    // I get here second.
    return Task.FromResult(0);
}

private Task OnSecurityTokenValidated(SecurityTokenValidatedNotification<OpenIdConnectMessage, OpenIdConnectAuthenticationOptions> n)
{
    // I get here first.
    return Task.FromResult(0);
}

While I still do get the error callback (from validation that’s happening here: https://github.com/aspnet/AspNetKatana/blob/main/src/Microsoft.Owin.Security.OpenIdConnect/OpenidConnectAuthenticationHandler.cs#L529), this is not enough because a user has already been validated by ID token and the ticket has already been created.

[Tratcher]

A secure implementation necessarily requires some linkage between cookie and state - sites can implement this as long-cookie+short-state or short-cookie+long-state, but generally long-cookie+short-state (e.g. with state as a UUID) is a little simpler.

We already have an implementation of short-cookie+long-state. The unique correlation cookie is verified against state field before any of the data in the state is consumed (including the PKCE value). A stolen state field cannot be re-used. Swapping the state and the cookie would not make this any more secure, it would only be a trade-off between cookie limits and url limits. Since url limits are more easily controlled/mitigated by the server we don’t plan on changing how this works.

Thanks @kevinchalet!

[kevinchalet]

@kevinchalet the problem is not in code verifier being extracted and decrypted, but rather the whole response query URL containing State and Code (in case of Response Mode = Query) being obviously available to your ISP, firewall/access logs, etc, which can easily be intercepted and used by a hacker.

You’re expected to use TLS so your ISP should never be able to access any of your query string parameters. Firewalls and applications can certainly log them, but since authorization codes are generally one-time tokens, it’s not considered a viable attack vector in most cases.

which can easily be intercepted and used by a hacker

You need to be more specific: used how? It’s one thing to pretend something is vulnerable to a class of attack, but you need to demonstrate it.