#c# #oauth #openid #identityserver3 #facebook-authentication
#c# #oauth #openid #identityserver3 #facebook-аутентификация
Вопрос:
Я включил IdentityServer для аутентификации в Facebook с помощью неявного потока.
теперь, когда я аутентифицируюсь, я получаю значение идентификатора в качестве субъекта. например 502967fe0125ce3ff75050ef7b83fd68 , я использовал его в качестве идентификатора пользователя для хранения пользовательских данных. Но время от времени кажется, что содержимое объекта меняется, и я получаю другой идентификатор.
Я не понимаю концепцию субъекта. Ожидается ли, что это вызывает беспокойство?
Не должен быть постоянным идентификатором субъекта? Какую информацию я должен использовать для хранения пользовательских данных?
Вот как я настраиваю поставщика facebook на identityserver:
public static void Configure(IAppBuilder app, string signInAsType)
{
var fb = new FacebookAuthenticationOptions
{
AuthenticationType = "Facebook",
Caption = "Facebook",
SignInAsAuthenticationType = signInAsType,
AppId = myAppId,
AppSecret = mySecret
};
app.UseFacebookAuthentication(fb);
}
И вот конфигурация клиента на веб-сайте
JwtSecurityTokenHandler.InboundClaimTypeMap = new Dictionary<string, string>();
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "cookies"
});
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
AuthenticationType = "oidc",
SignInAsAuthenticationType = "cookies",
ClientId = "website",
Authority = identServer,
RedirectUri = "http://localhost/pluto/",
ResponseType = "id_token token",
Scope = "openid profile email warehouseapi"
}
Комментарии:
1. Просто я задумался. Почему бы вам не использовать
SecurityTokenValidatedвместоAuthorizationCodeReceivedдля изменения утверждения о личности?2. используется код из примера из курса pluralsight
3. кстати, изменил его на securityTokenValidated. но все же время от времени тема меняется…
Ответ №1:
Дополнительное утверждение представляет уникальный идентификатор пользователя в контексте STS.
Обычно это означает, что при первом входе пользователя в систему создается новый подраздел. Затем этот подраздел связывается с внешним логином (имя эмитента и внешний подраздел) и используется повторно.
Комментарии:
1. итак, наиболее распространенным способом было бы теперь использовать пользователей в памяти, чтобы заставить его не меняться правильно? что было бы хорошим способом, если я также хочу иметь идентификатор facebook? Нужен ли мне пользовательский пользовательский сервис?
2. Вы никогда не будете использовать хранилище в памяти за пределами разработчиков, демонстраций или тестирования.
3. да, это ясно. В настоящее время я оцениваю только серверные функциональные возможности, и я начал с примеров из pluralsight, которые основаны на in memroy impl. А также я пытаюсь понять, в чем причины некоторых вещей, почему они ведут себя так, как они делают
Ответ №2:
Найдена причина. Возвращаемый идентификатор в sub является идентификатором пользователя сервера идентификации, а не идентификатором facebook. И поскольку я использую реализацию памяти, то при каждом перезапуске сервера идентификации идентификатор изменяется.
Итак, для меня это закрыто, но все еще остается вопрос, является ли это желательным поведением.
Должен ли быть более вероятным идентификатор facebook, который помещается в subject?
Комментарии:
1. Это имеет смысл. Facebook и все другие IDP должны возвращать один и тот же sub для одного и того же пользователя, в то же время было бы неплохо иметь свой собственный sub для этого пользователя в вашей собственной реализации identityserver.