Зачем использовать куки для аутентификации на основе токенов с использованием Identity Server и asp.net core 2 - PullRequest
0 голосов
/ 11 сентября 2018

Я создаю пример приложения, чтобы просто понять, как аутентификация на сервере удостоверений 4 работает с ядром Asp.net 2. Я заметил, что некоторые файлы cookie генерируются для разных уровней, как это видно на прикрепленном скриншоте.Мои проблемы, почему эти куки генерируются?

Ниже выписка из документа Identity Server.Когда идентификационный сервер настраивает

IdentityServer внутренне вызывает и AddAuthentication и AddCookie с пользовательской схемой (через константу IdentityServerConstants.DefaultCookieAuthenticationScheme),

Здесьпочему он вызывает метод AddCookies на самом сервере идентификации?

Также, когда я настраиваю основной веб-клиент Asp.net для использования аутентификации на сервере идентификации, он также вызывает метод AddCookie().Когда я пытаюсь это прокомментировать, это выдаст мне ошибку.Мне немного неясно, что здесь происходит.

Конфигурации Identity Server

services.AddIdentityServer()
                .AddDeveloperSigningCredential()
                .AddToDoUserStore()
                .AddInMemoryIdentityResources(Config.GetIdentityResources())
                .AddInMemoryApiResources(Config.GetApiResources())
                .AddInMemoryClients(Config.GetClients());

            services.AddAuthentication("MyCookie")
            .AddCookie("MyCookie", options =>
            {
                options.ExpireTimeSpan = new System.TimeSpan(0, 0, 15);
            });

Конфигурация веб-клиента

services.AddAuthentication(options =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
            })
            .AddCookie()
            .AddOpenIdConnect(options =>
            {
                options.Authority = "https://localhost:44377/";
                options.RequireHttpsMetadata = true;
                options.ClientId = "ToDoTaskManagmentClient";
                options.Scope.Clear();
                options.Scope.Add("openid");
                options.Scope.Add("profile");
                options.Scope.Add("address");
                options.Scope.Add("roles");
                options.Scope.Add("usertodoapi");
                options.Scope.Add("countries");
                options.Scope.Add("subscriptionlevel");
                options.Scope.Add("offline_access");
                options.ResponseType = "code id_token";
                options.SaveTokens = true;
                options.ClientSecret = "secret";
                options.GetClaimsFromUserInfoEndpoint = true;
                options.ClaimActions.Clear();
                options.ClaimActions.MapJsonKey("given_name", "given_name");
                options.ClaimActions.MapJsonKey("family_name", "family_name");
                options.ClaimActions.MapJsonKey("role", "role");
                options.ClaimActions.MapJsonKey("country", "country");
                options.ClaimActions.MapJsonKey("subscriptionlevel", "subscriptionlevel");
                options.Events = new OpenIdConnectEvents()
                {
                    OnTokenValidated = e =>
                    {
                        var identity = e.Principal;
                        var subjectClaim = identity.Claims.FirstOrDefault(z => z.Type == "sub");
                        var expClaims = identity.Claims.FirstOrDefault(z => z.Type == "exp");
                        var newClaimsIdentity = new ClaimsIdentity(e.Scheme.Name);
                        newClaimsIdentity.AddClaim(subjectClaim);
                        newClaimsIdentity.AddClaim(expClaims);

                        e.Principal = new ClaimsPrincipal(newClaimsIdentity);
                        return Task.FromResult(0);
                    },
                    OnUserInformationReceived = e =>
                    {
                        e.User.Remove("address");
                        return Task.FromResult(0);
                    }
                };
            });

enter image description here

Ответы [ 2 ]

0 голосов
/ 11 сентября 2018

Вашему приложению Identity Server требуется файл cookie аутентификации (и файл cookie идентификатора сеанса), чтобы конечные точки переднего канала (авторизация, согласие, check_session_iframe и, возможно, другие) знали, аутентифицирован ли пользователь или нет, и текущее состояние сеанса.Без этого он не знал бы, кто это называет.IDS4 автоматически перенаправит на URL-адрес для входа в систему по умолчанию, если обнаружит, что входящий запрос не аутентифицирован - тогда вы можете свободно использовать любой поток аутентификации, который вам нравится.

Ваши клиентские приложения могут или не могут требовать кукив зависимости от архитектуры.Для традиционных серверных веб-форм или приложений в стиле MVC потребуется один, но чистый JS-клиент, использующий такую ​​библиотеку, как oidc-client-js, не будет и может общаться с серверной частью исключительно с помощью токена доступа, полученного с вашего сервера идентификации.

0 голосов
/ 11 сентября 2018

IdentityServer не делает ничего из этого. Все, что он делает, это обрабатывает низкоуровневую аутентификацию / авторизацию и возвращает принципал утверждений. Ваше приложение, которое использует IdentityServer, должно установить cookie.

То, что вы здесь делаете, - это, по сути, один и тот же хост приложений, как IdentityServer, так и веб-интерфейс на основе проверки подлинности cookie. Часть «cookie» предназначена для традиционного пользовательского интерфейса потока входа в систему, поэтому приложение может распознать, прошел ли пользователь проверку подлинности, и перенаправить его на форму входа, на страницу учетной записи или обратно в исходное приложение, если или когда они прошли проверку подлинности.

Эта часть может быть полностью выделена в совершенно другое приложение, и тогда ваше приложение IdentityServer больше не будет нуждаться в конфигурации аутентификации cookie.

...