ASP.net MVC Core и IdentityServer 4: настройка defaultScheme в AddAuthentication - PullRequest
Новая
       81

ASP.net MVC Core и IdentityServer 4: настройка defaultScheme в AddAuthentication

0 голосов
/ 30 апреля 2018

Я смотрю на код ниже. В AddAuthentication добавлена ​​схема defaultScheme с «Cookies». Означает ли это, что текущее приложение mvc принимает только аутентификацию Cookie, но не токен доступа по умолчанию. 

services.AddOptions();
//services.Configure(Configuration);
services.AddDistributedMemoryCache(); // Adds a default in-memory implementation of IDistributedCache
services.AddSession();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies")
.AddOpenIdConnect("oidc", options =>
{

В настоящее время я хотел получить доступ к одной странице с моим мобильным приложением, которое аутентифицировалось с помощью токена доступа, который вошел в систему из самого приложения. Интересно, как я могу запросить веб-страницу внутри моего веб-просмотра, используя AccessToken вместо Cookie.

Существует нечто, называемое атрибутом Authorize с допустимой разницей в схеме, которую я могу передать. Интересно, так ли это настроить? 

[Authorize(AuthenticationSchemes = 
    JwtBearerDefaults.AuthenticationScheme)]

Это только для Accesstoken, если мне нужны оба файла, я также добавляю cookie

1 Ответ

0 голосов
/ 30 апреля 2018 
options.DefaultScheme = "Cookies";

Это означает, что схема аутентификации, если не указано иное, будет "Cookies". 

options.DefaultChallengeScheme = "oidc";

Это означает, что схема проверки подлинности по умолчанию, если не указано иное, будет "oidc".

Вот как схемы аутентификации OIDC и Cookie обычно работают друг с другом: приложение попытается аутентифицировать пользователя, используя существующий файл cookie. Если это не удается (потому что нет файла cookie), тогда будет выполнена проверка подлинности с использованием схемы OIDC. Это затем передаст аутентификацию внешнему провайдеру, и, когда это удастся, схема OIDC подпишет пользователя, используя схему аутентификации Cookie. Это создает cookie, поэтому при следующем запросе схема проверки подлинности cookie сможет аутентифицировать пользователя (без необходимости повторного запроса схемы OIDC).

Если вы хотите, чтобы другие схемы аутентификации работали, вам придется добавить и их. AddAuthentication(…).AddCookie(…).AddOpenIdConnect(…) просто настроит эту цепочку. Если вы также хотите аутентификацию на носителе JWT, вам также необходимо настроить ее.

Но только потому, что вы .AddJwtBearer(…), это не означает, что что-либо в обычном потоке изменится: схема Cookie по-прежнему будет использоваться по умолчанию, а схема OIDC по-прежнему будет вызовом по умолчанию. Как я уже говорил выше: если не указано иное.

Так что, если вы хотите авторизовать пользователя с использованием аутентификации JWT Bearer, вам необходимо явно активировать его. Как вы уже заметили, это можно сделать с помощью атрибута Authorize. Но для того, чтобы это сработало, вам все равно придется правильно настроить аутентификацию JWT Bearer. Но тогда он может работать параллельно с уже настроенной настройкой Cookie / OIDC.

...