Использование IProfileService при входе через Google OAuth

Я пытаюсь изменить образец IdentityServer4 AspNetIdentity, чтобы иметь возможность входить в систему как для локальных пользователей, так и для Google.

Я смог сделать это, добавив аутентификацию Google:

        app.UseIdentity();
        app.UseIdentityServer();

        var cookieScheme = app.ApplicationServices.GetRequiredService<IOptions<IdentityOptions>>().Value.Cookies.ExternalCookieAuthenticationScheme;

        // Add external authentication middleware below. To configure them please see http://go.microsoft.com/fwlink/?LinkID=532715
        app.UseGoogleAuthentication(new GoogleOptions
        {
            AuthenticationScheme = "Google",
            SignInScheme = cookieScheme,
            ClientId = "client_id",
            ClientSecret = "client_secret"
        });

Как и ожидалось, на главной странице отображаются правильные утверждения пользователей:

sub
c51da331-0348-45dd-352f-08d4526f6266
name
[email protected]
AspNet.Identity.SecurityStamp
568a167f-a431-4f70-ba66-918f99e95eef
idp
Google
amr
external
auth_time
1486815555

Когда пользователь впервые входит в систему с помощью учетной записи Google, я добавляю некоторую информацию в базу данных, и я подумал, что могу добавить их к утверждениям пользователя, используя настраиваемую реализацию IProfileService и настраивая IdentityServer для использования моего настраиваемого IProfileService:

         var builder = services.AddIdentityServer();
         builder.AddTemporarySigningCredential();

        builder.AddConfigurationStore(b => b.UseSqlServer(connectionString, options => options.MigrationsAssembly(migrationAssembly)));
        builder.AddOperationalStore(b => b.UseSqlServer(connectionString, options => options.MigrationsAssembly(migrationAssembly)));
        builder.AddAspNetIdentity<MyUser>();
        builder.AddProfileService<MyCustomProfileService>();

Но теперь, когда я перехожу на главную страницу, утверждения пользователей остаются прежними, и даже метод GetProfileDataAsync не работает.

Я ценю, если кто-нибудь может сказать мне, что это такое.


asp.net-core identityserver4 asp.net-core-mvc asp.net-core-identity
person mrtaikandi    schedule 11.02.2017    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Оказывается, IdentityServer не будет использовать IProfileService для добавления пользовательских утверждений, если он настроен на использование библиотеки идентификаторов ASP.NET, если только (как указано в @Set) конечная точка UserInfo вызывается напрямую. Подход к разработке заключается в использовании механизма идентификации ASP.NET для создания утверждений путем регистрации IUserClaimsPrincipalFactory.

В этом случае мы можем либо создать настраиваемую реализацию IUserClaimsPrincipalFactory, либо, поскольку ASP.NET Identity будет загружать любые дополнительные утверждения, хранящиеся в базе данных, добавить любые дополнительные утверждения, используя AddClaimsAsync метода UserManager класс.

person mrtaikandi    schedule 12.02.2017

arrow_upward
2
arrow_downward

Согласно обсуждению в Добавление настраиваемых утверждений в реализацию ASPNET Core Identity на github, GetProfileDataAsync Метод вызывается только в том случае, если утверждения необходимо поместить в токен. Также есть ссылка на Оптимизация токенов идентификации по размеру , в котором объясняется, что IdentityServer по умолчанию ведет себя в соответствии со спецификацией OpenID Connect, которая предлагает следующее (в разделе 5.4):

Утверждения, запрошенные значениями профиля, электронной почты, адреса и телефона, возвращаются из конечной точки UserInfo, как описано в Разделе 5.3.2, когда используется значение response_type, которое приводит к выдаче токена доступа. Однако, когда токен доступа не выдается (что имеет место для значения response_type id_token), результирующие утверждения возвращаются в токене идентификатора.

Другими словами, если запрошен только токен идентификации, поместите все утверждения в токен. Если, однако, также запрошен токен доступа => удалите утверждения из токена идентификации и позвольте клиенту использовать конечную точку userinfo для их получения.

Однако можно изменить это поведение по умолчанию, установив флаг AlwaysIncludeUserClaimsInIdToken в конфигурации клиента (подробнее this).

person Set    schedule 11.02.2017