0

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

я был в состоянии сделать это, добавив аутентификации 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" 
     }); 

Как и ожидалось мнение Home показывает правильные требования пользователя:

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 не ударит.

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

ответ

2

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

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

2

В соответствии с обсуждением в Adding Custom Claims to an ASPNET Core Identity Implementation на github метод GetProfileDataAsync вызывается только в том случае, если претензии должны быть помещены в токен. Также он имеет ссылку на Optimizing Identity Tokens for size пост, который объясняет, что IdentityServer по умолчанию имеет поведение в соответствии со спецификацией OpenID Connect, что позволяет сделать следующие выводы (в разделе 5.4):

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

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

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