Sometimes get a "idp claim is missing" with AspNetIdentity when authorizing

[liamdawson]

System.InvalidOperationException: idp claim is missing
   at IdentityServer4.Extensions.PrincipalExtensions.GetIdentityProvider(IIdentity identity) in IdentityServer4-1.0.0-rc1\src\IdentityServer4\Extensions\PrincipalExtensions.cs:line 184}   System.InvalidOperationException

IS4 entries in project.json:

"IdentityServer4": "1.0.0-rc1",
"IdentityServer4.AspNetIdentity": "1.0.0-rc1",
"IdentityServer4.AccessTokenValidation": "1.0.0-rc1" (resolving to 1.0.1-beta1)

I'm using ASP.Net Core Identity, and I've included the IdentityServer4 token validation library (I want to secure an api for user creation etc as part of the same service).

Here are the claims that are set on the current identity:

[0]: "sub: 3b26b2f3-ed9d-4ca0-9fd1-cb686484002d"
[1]: "name: liam@example.com"
[2]: "AspNet.Identity.SecurityStamp: eccf3972-e976-450d-a5a2-3be969616786"
[3]: "role: sysadmin"
[4]: "mp.sysadmin: true"
[5]: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname: Liam"
[6]: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname: Dawson"

Is this just a "we should allow returning null for the provider"? Or is there a further underlying issue/misconfiguration? In this instance, I'm only supporting one IDP, so I don't personally mind a bandaid fix.

[leastprivilege]

How do you sign in the user?

[liamdawson]

Via a login endpoint. In this instance, the idp claim issue arose after automatically being accepted as being logged in (via cookies).

[liamdawson]

Entirety of the login endpoint:

        [AllowAnonymous]
        [HttpPost]
        public async Task<IActionResult> Login(LoginViewModel model, string redirectUrl = null)
        {
            if (!ModelState.IsValid)
            {
                var errors = ModelState.Values.SelectMany(v => v.Errors).Select(e => e.ErrorMessage ?? e.Exception?.Message); 
                _logger.LogWarning("Login request was invalid. Errors: {errors}, Password provided for {username}: {password_provided}.",
                    errors,
                    model.Email,
                    !string.IsNullOrEmpty(model.Password));
                return StatusCode(StatusCodes.Status400BadRequest);
            }

            var result = await _signInManager.PasswordSignInAsync(model.Email,
                model.Password,
                model.RememberMe ?? false,
                true);

            if (result.Succeeded)
            {
                return Redirect(string.IsNullOrEmpty(redirectUrl) ? "/" : redirectUrl);
            }

            return StatusCode(StatusCodes.Status403Forbidden);
        }

(which wasn't called in this instance, because already logged in)

[leastprivilege]

I see - so it maybe happens when the gets "slided" ? @brockallen ?

[kdaveid]

I have made the same experiences. Usually this happens when (in dev) I restart the auth server (IdentityServer4) but not the MVC client and make a new request to an [Authorize]'d method within MVC app. The exact behavior I'll probably see today as I'll go further with implementing.

[brockallen]

Possibly. I did have a reminder for myself to look into this.

[ManuelRauber]

I can confirm this behavior using ASP.NET Core Identity, too.

SPA with Implicit using the popup mode. Code is the same as in your quickstarter examples.

[brockallen]

The cookie does not lose any claims when it slides, but it will lose claims if the security stamp is invalidated. Is this perhaps what you're running into?

If any of you having this issue can confirm that it's not the cookie sliding, but instead the security stamp validation I'd appreciate it. Thanks!

[brockallen]

BTW, the properties are not lost so what we'll have to do is either 1) store these crucial claims in the properties, and then reload the claims from the properties, or, the less desirable option, 2) in our AddAspNetIdentity we replace the security stamp validator with all of the exact same logic as the built-in one, but instead we reload from the current claims rather than from the DB.

[liamdawson]

security stamp validation

How exactly is this validation performed? As in, is it ASP.Net identity related, and could it happen due to a server restart (I haven't explicitly set any secrets or anything about Identity)

[brockallen]

It's automatic within ASP.NET Identity. When anything related to the user's authentication changes (password, 2fa settings, email settings, etc). You can tell by the security stamp claim changing in the user's cookie.

If you can't tell, then can you narrow down the exact repro steps so I can make sure what I'm seeing matches what you're seeing? Thanks.

[liamdawson]

Unfortunately, I haven't found a consistent repro. Haven't made any changes to the user, though, at all.

[brockallen]

To test this I did these things:

1. set the cookie to be sliding and set the expiration to be low so i could see when the cookie slid. when the cookie slides i see all the same claims, so that's why i'm not thinking it's that.

2. login and then change the user's 2fa settings (or change password, or something else to affect the security stamp). then i saw that the claims issued at login time as lost (including idp). since the cookie renewal is done within the cookie middleware (and not from the mvc code) then we don't have a chance to augment the claims being added so you lose the crucial claims issues issued at at login time (they just reload claims from the ASP.NET Identity DB). that's why i opened the issue in the ASP.NET Identity repo, as this is not ideal behavior IMO.

[takazm]

I am getting the same exception idsvr aspnet core, client aspnet core. Also happens when auto authenticated through cookie.

Unhandled exception: System.InvalidOperationException: idp claim is missing .....

at IdentityServer4.Extensions.PrincipalExtensions.GetIdentityProvider(IIdentity identity)

[damienbod]

I have this problem as well, OpenID Connect Implicit Flow.

https://github.com/damienbod/AspNet5IdentityServerAngularImplicitFlow

I can reproduce it by logging on directly to IdentityServer4, and then starting the SPA and the Implicit Flow login request causes this problem.

Greetings Damien

[brockallen]

Ok, I now understand better what's happening. ASP.NET Identity always reloads the user's claims from the DB every 15m by default. This is done by the security stamp validator, but that behavior is odd given that it seems orthogonal the intended purpose of the security stamp validator.

Anyway, I am now very confident that this is the reason behind this issue. I'll keep everyone posted on what we're going to do.

[brockallen]

Ok, I've added a custom security stamp validator to not reload claims from the DB. IdentityServer4.AspNetIdentity 1.0.0-rc1-update2 has been released to NuGet. Please test it and let us know how it's working.

[hmheng]

[remove]

[kdaveid]

Ok, so there is what I experienced so far. Before 1.0.0-rc1-update2 the missing idp issue occurred when I signed out of the client (MVC app) but the idsvr was offline and could not receive the redirect/offline request.

Sign out in mvc:

await HttpContext.Authentication.SignOutAsync("Cookies");
await HttpContext.Authentication.SignOutAsync("oidc");

When I then started an instance of idsvr and reloaded the mvc page or tried to get to an secured page ([Authorized]) it would throw the System.InvalidOperationException: idp claim is missing.

Doing these steps is probably not the use case and I haven't digged into the whole problem so I don't know if this is by design or just me being inconsistent in (re-)starting servers...

Anyway, with 1.0.0-rc1-update2 this does not happen anymore.

[damienbod]

I have updated and done some initial tests. I cannot reproduce this problem anymore.

Greetings Damien

[brockallen]

Ok, good to hear. Thanks.

[aggieben]

@brockallen I'm experiencing this issue as well.

Ok, I now understand better what's happening. ASP.NET Identity always reloads the user's claims from the DB every 15m by default. This is done by the security stamp validator, but that behavior is odd given that it seems orthogonal the intended purpose of the security stamp validator.

I don't understand this. Why would periodically reloading the user's claims cause this problem?

[brockallen]

I don't understand this. Why would periodically reloading the user's claims cause this problem?

Because idp is a claim captured at login time, and is not something stored in the DB.

[aggieben]

Ok, I follow that. This issue appears for me right off the bat though, and it's 100% of the time - it smells like a misconfiguration on my part, but I am having a hard time figuring out what it would be.

[aggieben]

For anyone else who might have landed here: It's important to call app.UseIdentityServer() before calling app.UseMvc() in the Configure() method of the Startup class. Getting them out of order will result in this issue as well.

[artiomchi]

@brockallen @aggieben
I'm upgrading an app that was previously using IdentityServer3. Because of the way it work, the identity server was hosted under /auth, so that was the authority for external apps.

Moving on to IdentityServer4, I can have the root url be the authority (nice, by the way!), but I've got external clients that authenticate with our system, so changing the authority url is no easy feat. I've experimented with the QuickStart6 project, and tried the following:

app.UseIdentity();

app.Map("/auth", authApp =>
{
    authApp.UseIdentityServer();
});

app.UseMvc(routes =>
{
    routes.MapRoute(
        name: "default",
        template: "{controller=Home}/{action=Index}/{id?}");
});

This causes the aforementioned idp claim is missing error. Authenticating in the API project works well, but authenticating from the MVC app does now. Even though UseMvc() is registered after .UseIdentityServer(), I'm guessing the fact that it's under a child url is causing this issue.

Is there a better way to do this, or does this mean this issue is still active?

[liamdawson]

@artiomchi the map method doesn't fall through, as such, to the middleware underneath - therefore, MVC is not configured for the /auth routes. What happens if you copy the use mvc method into the Map method?

[artiomchi]

Nope, seems to be running into the same issue.

I've tried

app.Map("/auth", authApp =>
{
    authApp.UseIdentityServer();
    authApp.UseMvcWithDefaultRoute();
});

Actually, doing some more testing and I uncovered some interesting things..

1. Logging out of both server and client sites, clearing cookies. Adding UseMvcWithDefaultRoute() as part of the /auth Map.
   When I try to go to the secure page on the client, it sends me to the login page (BUT it's on /auth/account/login, because of the new mvc rule, styles and js fail to load). BUT the authentication process goes through!
2. Using UseMvc() instead of UseMvcWithDefaultRoute() in /auth. Cleared cookies. When trying to go to the secure page, I get redirected to /auth/account/login, which returns a 404. Fixing the url (removing auth), sends me to the login page, but after logging in I get a idp claim is missing.
3. not adding UseMvc() at all for /auth has the same effect as in point 2, including the redirect to /auth/account/login

So my guess is that within IdentityServer, the base url gets set, which affects all requests and URL builds to the site, including redirects to the login pages.

I did a quick glance at the code, and something like that is being set here, but without a deeper code analysis, I might just be looking at a red herring :)
https://github.com/IdentityServer/IdentityServer4/blob/dev/src/IdentityServer4/Hosting/BaseUrlMiddleware.cs#L28

[artiomchi]

P.S. Just tried restricting the child route to only catch the Connect controller, and it behaves the same as points 2/3 above

app.Map("/auth", authApp =>
{
    authApp.UseIdentityServer();
    authApp.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "Connect/{action=Index}/{id?}",
            defaults: new { Controller = "Connect" });
    });
});

[liamdawson]

You can override the login/etc urls when you add identity server in the configure services section. Maybe combining your first attempt with that to ensure it goes to the right page for JS etc would be a temporary workaround?

…

On Thu, Jun 8, 2017, 21:33 Artiom Chilaru ***@***.***> wrote: P.S. Just tried restricting the child route to only catch the Connect controller, and it behaves the same as points 2/3 above app.Map("/auth", authApp => { authApp.UseIdentityServer(); authApp.UseMvc(routes => { routes.MapRoute( name: "default", template: "Connect/{action=Index}/{id?}", defaults: new { Controller = "Connect" }); }); }); — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#277 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuZT2nV3t6m-wb8eQ2grAXk_SoFJd74ks5sB9wbgaJpZM4J4uYT> .

[artiomchi]

So... You mean something like this?

services.AddIdentityServer(x =>
    {
        x.UserInteraction.LoginUrl = "/account/login";
    })

Nope.. It builds the login url based on the relative path. Just to be sure, I changed it to /account/login2, and I've been redirected to /auth/account/login2.

Could this issue be re-opened or a new issue created for this, as this means I can't use the IS4 at all in my current environment, and that prevents me from upgrading to ASP.NET Core MVC :(

[leastprivilege]

open a new issue

[antonioromano]

I'm experiencing the same issue, I'm using IdentityServer4 and from time to time I found in logs 'Unhandled exception: System.InvalidOperationException: idp claim is missing' or 'IdentityServer4 message: idp claim is missing stack: at IdentityServer4.Extensions.PrincipalExtensions.GetIdentityProvider(IIdentity identity)'.
When I experience this the only solution is to logout and login again

[YZahringer]

The issue is back with version 2.0.0-rc1.

[gato-negro]

Same as @YZahringer after upgrading to 2.0.0-rc1

[nukec]

Same issue here:
InvalidOperationException: sub claim is missing

[gato-negro]

Any updates on this?

[antonioromano]

Since this issue has been closed I opened a new one here: #1573
Please support and comment it

[brockallen]

Just as a follow on note here about this issue. This error happens when you don't have the main authentication cookie scheme set as the default sign-in scheme in ASP.NET Core. This is usually the case when you use ASP.NET Identity, because it internally set the sign in scheme to be the external authentication cookie scheme.

[sjh37]

If it helps, I have just got this problem when using Postman, and Requesting an 'Authorization Code' token.

Nuget packages:

IdentityServer4 v2.3.2
IdentityServer4.AspNetIdentity v2.3.0
IdentityServer4.EntityFramework v2.3.2

Stacktrace:

System.InvalidOperationException: idp claim is missing
   at IdentityServer4.Extensions.PrincipalExtensions.GetIdentityProvider(IIdentity identity) in C:\local\identity\server4\IdentityServer4\src\Extensions\PrincipalExtensions.cs:line 203
   at IdentityServer4.ResponseHandling.AuthorizeInteractionResponseGenerator.ProcessLoginAsync(ValidatedAuthorizeRequest request) in C:\local\identity\server4\IdentityServer4\src\ResponseHandling\Default\AuthorizeInteractionResponseGenerator.cs:line 160
   at IdentityServer4.ResponseHandling.AuthorizeInteractionResponseGenerator.ProcessInteractionAsync(ValidatedAuthorizeRequest request, ConsentResponse consent) in C:\local\identity\server4\IdentityServer4\src\ResponseHandling\Default\AuthorizeInteractionResponseGenerator.cs:line 83
   at IdentityServer4.Endpoints.AuthorizeEndpointBase.ProcessAuthorizeRequestAsync(NameValueCollection parameters, ClaimsPrincipal user, ConsentResponse consent) in C:\local\identity\server4\IdentityServer4\src\Endpoints\AuthorizeEndpointBase.cs:line 81
   at IdentityServer4.Endpoints.AuthorizeEndpoint.ProcessAsync(HttpContext context) in C:\local\identity\server4\IdentityServer4\src\Endpoints\AuthorizeEndpoint.cs:line 55
   at IdentityServer4.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events) in C:\local\identity\server4\IdentityServer4\src\Hosting\IdentityServerMiddleware.cs:line 54
   at IdentityServer4.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events) in C:\local\identity\server4\IdentityServer4\src\Hosting\IdentityServerMiddleware.cs:line 69
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.Invoke(HttpContext context)
   at IdentityServer4.Hosting.BaseUrlMiddleware.Invoke(HttpContext context) in C:\local\identity\server4\IdentityServer4\src\Hosting\BaseUrlMiddleware.cs:line 36
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

To clarify, changing:

services.AddAuthentication()
    .AddCookie("Cookies")

to

services.AddAuthentication("Cookies")
    .AddCookie("Cookies")

Makes the idp claim is missing go away, however I now get another problem, which is a login loop, the login succeedes, but then i'm right back at the login page again. The log of which is here:

[16:53:39.524 INF] Request starting HTTP/1.1 POST https://localhost:5001/Account/Login?ReturnUrl=%2Fgrants application/x-www-form-urlencoded 329
[16:53:39.541 INF] Route matched with {action = "Login", controller = "Account", page = "", area = ""}. Executing action IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth)
[16:53:39.558 INF] Executing action method IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth) with arguments (["IdentityServer4.Quickstart.UI.LoginInputModel", "login"]) - Validation state: Valid
[16:53:39.577 INF] Entity Framework Core 2.1.4-rtm-31024 initialized 'ApplicationDbContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options: SensitiveDataLoggingEnabled
[16:53:39.596 INF] Executed DbCommand (2ms) [Parameters=[@__normalizedUserName_0='SIMON.HUGHES@ZAPINAMO.COM' (Size = 256)], CommandType='Text', CommandTimeout='30']
SELECT TOP(1) [u].[Id], [u].[AccessFailedCount], [u].[ConcurrencyStamp], [u].[Email], [u].[EmailConfirmed], [u].[LockoutEnabled], [u].[LockoutEnd], [u].[NormalizedEmail], [u].[NormalizedUserName], [u].[PasswordHash], [u].[PhoneNumber], [u].[PhoneNumberConfirmed], [u].[SecurityStamp], [u].[TwoFactorEnabled], [u].[UserName]
FROM [AspNetUsers] AS [u]
WHERE [u].[NormalizedUserName] = @__normalizedUserName_0
[16:53:39.626 INF] Executed DbCommand (2ms) [Parameters=[@__normalizedUserName_0='SIMON.HUGHES@ZAPINAMO.COM' (Size = 256)], CommandType='Text', CommandTimeout='30']
SELECT TOP(1) [u].[Id], [u].[AccessFailedCount], [u].[ConcurrencyStamp], [u].[Email], [u].[EmailConfirmed], [u].[LockoutEnabled], [u].[LockoutEnd], [u].[NormalizedEmail], [u].[NormalizedUserName], [u].[PasswordHash], [u].[PhoneNumber], [u].[PhoneNumberConfirmed], [u].[SecurityStamp], [u].[TwoFactorEnabled], [u].[UserName]
FROM [AspNetUsers] AS [u]
WHERE [u].[NormalizedUserName] = @__normalizedUserName_0
[16:53:39.654 INF] Executed DbCommand (3ms) [Parameters=[@p14='8020f330-afe1-45dc-8d5a-a02e8947a39f' (Nullable = false) (Size = 450), @p0='0', @p1='ec830501-dc72-4d63-ba1b-a25d7404b036' (Size = 4000), @p15='942e83a1-2503-4884-94af-de30a005709e' (Size = 4000), @p2='simon.hughes@zapinamo.com' (Size = 256), @p3='True', @p4='True', @p5='' (DbType = DateTimeOffset), @p6='SIMON.HUGHES@ZAPINAMO.COM' (Size = 256), @p7='SIMON.HUGHES@ZAPINAMO.COM' (Size = 256), @p8='AQAAAAEAACcQAAAAECy9cAXwuvQuS4Twqst/rRNNnbcWXNHVuauLSgZ2GQFH5oFIG04IHUD/QI0nAJO/lg==' (Size = 4000), @p9='' (Size = 4000), @p10='False', @p11='U4UVIGVLETFVPEDDTKPD3Y5E5T5PFNZR' (Size = 4000), @p12='False', @p13='simon.hughes@zapinamo.com' (Size = 256)], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
UPDATE [AspNetUsers] SET [AccessFailedCount] = @p0, [ConcurrencyStamp] = @p1, [Email] = @p2, [EmailConfirmed] = @p3, [LockoutEnabled] = @p4, [LockoutEnd] = @p5, [NormalizedEmail] = @p6, [NormalizedUserName] = @p7, [PasswordHash] = @p8, [PhoneNumber] = @p9, [PhoneNumberConfirmed] = @p10, [SecurityStamp] = @p11, [TwoFactorEnabled] = @p12, [UserName] = @p13
WHERE [Id] = @p14 AND [ConcurrencyStamp] = @p15;
SELECT @@ROWCOUNT;
[16:53:39.683 INF] Executed DbCommand (1ms) [Parameters=[@__user_Id_0='8020f330-afe1-45dc-8d5a-a02e8947a39f' (Size = 450)], CommandType='Text', CommandTimeout='30']
SELECT [uc].[Id], [uc].[ClaimType], [uc].[ClaimValue], [uc].[UserId]
FROM [AspNetUserClaims] AS [uc]
WHERE [uc].[UserId] = @__user_Id_0
[16:53:39.703 INF] AuthenticationScheme: Identity.Application signed in.
[16:53:39.723 INF] Executed DbCommand (3ms) [Parameters=[@__normalizedUserName_0='SIMON.HUGHES@ZAPINAMO.COM' (Size = 256)], CommandType='Text', CommandTimeout='30']
SELECT TOP(1) [u].[Id], [u].[AccessFailedCount], [u].[ConcurrencyStamp], [u].[Email], [u].[EmailConfirmed], [u].[LockoutEnabled], [u].[LockoutEnd], [u].[NormalizedEmail], [u].[NormalizedUserName], [u].[PasswordHash], [u].[PhoneNumber], [u].[PhoneNumberConfirmed], [u].[SecurityStamp], [u].[TwoFactorEnabled], [u].[UserName]
FROM [AspNetUsers] AS [u]
WHERE [u].[NormalizedUserName] = @__normalizedUserName_0
[16:53:39.743 INF] {"Username": "simon.hughes@zapinamo.com", "Provider": null, "ProviderUserId": null, "SubjectId": "8020f330-afe1-45dc-8d5a-a02e8947a39f", "DisplayName": "simon.hughes@zapinamo.com", "Endpoint": "UI", "Category": "Authentication", "Name": "User Login Success", "EventType": "Success", "Id": 1000, "Message": null, "ActivityId": "0HLJN3G9C928S:00000009", "TimeStamp": "2019-01-10T16:53:39.0000000Z", "ProcessId": 31492, "LocalIpAddress": "::1:5001", "RemoteIpAddress": "::1", "$type": "UserLoginSuccessEvent"}
[16:53:39.762 INF] Executed action method IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth), returned result Microsoft.AspNetCore.Mvc.RedirectResult in 185.2064ms.
[16:53:39.778 INF] Executing RedirectResult, redirecting to /grants.
[16:53:39.794 INF] Executed action IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth) in 236.6957ms
[16:53:39.812 INF] Request finished in 287.9275ms 302
[16:53:39.834 INF] Request starting HTTP/1.1 GET https://localhost:5001/grants
[16:53:39.851 INF] Route matched with {action = "Index", controller = "Grants", page = "", area = ""}. Executing action IdentityServer4.Quickstart.UI.GrantsController.Index (Zapinamo.Auth)
[16:53:39.865 INF] Authorization failed.
[16:53:39.880 INF] Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'.
[16:53:39.894 INF] Executing ChallengeResult with authentication schemes ([]).
[16:53:39.908 INF] AuthenticationScheme: Cookies was challenged.
[16:53:39.923 INF] Executed action IdentityServer4.Quickstart.UI.GrantsController.Index (Zapinamo.Auth) in 58.0712ms
[16:53:39.937 INF] Request finished in 102.9621ms 302
[16:53:39.959 INF] Request starting HTTP/1.1 GET https://localhost:5001/Account/Login?ReturnUrl=%2Fgrants
[16:53:39.977 INF] Route matched with {action = "Login", controller = "Account", page = "", area = ""}. Executing action IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth)
[16:53:39.994 INF] Executing action method IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth) with arguments (["/grants"]) - Validation state: Valid
[16:53:40.012 INF] Executed action method IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth), returned result Microsoft.AspNetCore.Mvc.ViewResult in 0.0421ms.
[16:53:40.028 INF] Executing ViewResult, running view Login.
[16:53:40.047 INF] Executed ViewResult - view Login executed in 19.1944ms.
[16:53:40.069 INF] Executed action IdentityServer4.Quickstart.UI.AccountController.Login (Zapinamo.Auth) in 75.2286ms
[16:53:40.089 INF] Request finished in 129.7875ms 200 text/html; charset=utf-8

[sjh37]

Solved

In order to get the following working again:

services.AddAuthentication()
    .AddCookie("Cookies")

I had to delete the users from the database, then re-add them. And magically idp claim is missing went away. So changing the authentication scheme after a user is created is going to end up with this error as the user is altered in the database.

To replicate the error use:

services.AddAuthentication()
    .AddCookie("Cookies")

Add a user and check you can login ok.
Change the code to:

services.AddAuthentication("Cookies")
    .AddCookie("Cookies")

Go to view grants, and you should now be stuck in a login loop.
Change the code back to:

services.AddAuthentication()
    .AddCookie("Cookies")

You now get the `idp claim is missing'

To solve, delete the user, and re-add user again. So something in the AspNetUsers table changed.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.