identity server что это
IdentityServer для собственных приложений в облаке
IdentityServer — это сервер проверки подлинности, который реализует стандарты openid connect Подключение (OIDC) и OAuth 2,0 для ASP.NET Core. Он предназначен для предоставления общего способа проверки подлинности запросов ко всем приложениям независимо от того, являются ли они веб-приложениями, собственными, мобильными или интерфейсными конечными точками API. IdentityServer можно использовать для реализации единого Sign-On (единого входа) для нескольких приложений и типов приложений. Его можно использовать для проверки подлинности реальных пользователей с помощью форм входа и аналогичных пользовательских интерфейсов, а также для проверки подлинности на основе служб, которая обычно включает выдачу, проверку и обновление маркеров без какого-либо пользовательского интерфейса. IdentityServer разработана как настраиваемое решение. Каждый экземпляр обычно настраивается в соответствии с потребностями конкретной организации и/или набора приложений.
Распространенные сценарии веб-приложений
Как правило, приложения должны поддерживать некоторые или все из следующих сценариев:
Рис. 8-1. Типы приложений и сценарии.
В каждом из этих сценариев предоставленная функциональность должна быть защищена от несанкционированного использования. Как минимум, обычно требуется проверка подлинности пользователя или участника, выполняющего запрос ресурса. эта проверка подлинности может использовать один из нескольких распространенных протоколов, таких как SAML2p, WS-подача или openid connect Подключение. Взаимодействие с API обычно использует протокол OAuth2 и его поддержку для маркеров безопасности. Отделение этих критических проблем безопасности и их реализация от самих приложений обеспечивает согласованность и повышает безопасность и удобство обслуживания. Аутсорсинг этих задач на выделенный продукт, такой как IdentityServer, позволяет каждому приложению решить эти проблемы самостоятельно.
IdentityServer предоставляет по промежуточного слоя, которое выполняется в приложении ASP.NET Core и добавляет поддержку openid connect Подключение и OAuth2 (см. поддерживаемые спецификации). организации создают собственное ASP.NET Core приложение с помощью по промежуточного слоя IdentityServer, которое действует как STS для всех своих протоколов безопасности на основе маркеров. По промежуточного слоя IdentityServer предоставляет конечные точки для поддержки стандартных функций, в том числе:
Начало работы
IdentityServer4 доступен по двум лицензиям:
Конфигурация
IdentityServer поддерживает различные типы протоколов и поставщиков проверки подлинности, которые можно настроить в рамках каждой выборочной установки. обычно это делается в классе ASP.NET Core приложения Startup в ConfigureServices методе. Конфигурация включает в себя указание поддерживаемых протоколов и пути к серверам и конечным точкам, которые будут использоваться. На рис. 8-2 показан пример конфигурации, взятой из проекта пользовательского интерфейса быстрого запуска IdentityServer4:
Рис. 8-2. Настройка IdentityServer.
IdentityServer4. Основные понятия. OpenID Connect, OAuth 2.0 и JWT
Этим постом я хочу открыть ветку статей посвященную IdentityServer4. Начнем мы с основных понятий.
Самым перспективным на текущий момент протоколом аутентификации является OpenID Connect, а протоколом авторизации (предоставления доступа) является OAuth 2.0. IdentityServer4 реализует эти два протокола. Он оптимизирован для решения типичных проблем безопасности.
OpenID Connect — это протокол и стандарт аутентификации, он не дает доступ к ресурсам (Web API), но т.к. он разработан поверх протокола авторизации OAuth 2.0, он позволяет получить параметры профиля пользователя как будто вы получили доступ к ресурсу UserInfo.
JWT (JSON Web Token) представляет собой веб-стандарт, который определяет способ передачи данных о пользователе в формате JSON в зашифрованном виде.
OAuth 2.0 (RFC 6749) — это протокол и стандарт авторизации. Он позволяет приложениям получить доступ к защищенным ресурсам, например к Web API.
Взглянем на диаграмму обращения к защищенному ресурсу и разберемся с основными шагами и принятой терминологией:
Клиент запрашивает у пользователя разрешение пройти авторизацию от его имени. Клиент — это клиентское приложение обращающиеся к защищённым ресурсам от имени владельца ресурсов. Ресурс — это все наши защищенные сервисы Web API.
User разрешает клиентскому приложению пройти авторизацию от его имени, например, вводит логин и пароль. Логин и пароль будут являться грантом авторизации для клиентского приложения. User (владелец ресурса) — программа или человек, который может выдать доступ к защищённым ресурсам, например, путем ввода логина (username) и пароля (password);
Если подлинность приложения подтверждена и разрешение на авторизацию действительно, IdentiryServer4 создаёт access-токен (токен доступа) для приложения и необязательный ключ обновления ( refresh-токен ). Процесс авторизации завершён. Если запрос недопустимый или несанкционированный, то сервер авторизации возвращает код с соответствующим сообщением об ошибке.
Клентское приложение обращается за данными к защищенному Web API, предоставляя при этом токен доступа для авторизации. Если код ответа сервера ресурсов 401, 403 или 498, то токен доступа, используемый для аутентификации, недействителен или просрочен.
Если токен действителен, Web API предоставляет данные приложению.
Типы токенов
Введем еще два понятия:
Authenticatation Server Url — конечная точка для получения ключа доступа. Все запросы на предоставление и возобновление ключей доступа будем направлять на этот URL-адрес.
Resource Url — URL-адрес защищенного ресурса, по которому нужно обращаться, чтобы получить доступ к нему, передавая ему ключ доступа в заголовке авторизации.
Запрос ключа доступа
Для запроса ключа доступа клиент делает POST запрос к конечной точке IdentityServer4 со следующим заголовком
и передавая следующие параметры:
Протокол OAuth 2.0 определяет следующие типы грантов требующие обязательного взаимодействие с пользователям:
И типы грантов, которые могут выполняться без интерактивного взаимодействия с пользователям:
scope — это необязательный параметр. Он определяет область видимости. Токен доступа, возвращенный сервером, будет обеспечивать доступ только к тем службам, которые входят в эту область. Т.е. мы можем несколько служб объединить под одним scope и если клиент получает ключ доступа к этому scope он получает доступ ко всем этим службам. Также scope может использоваться для ограничения прав авторизации (например, доступ на чтение или запись)
IdentityServer, HttpClient и всё такое
Давно надо было опробовать IdentityServer4, который Microsoft выпустила три года назад, в декабре 2016-го.
IdentityServer4 — это полуфабрикат, из которого легко собрать работающий сервер аутентификации за двадцать минут. Если вы знаете, как его собирать.
Он реализует стандарты OpenID Connect и OAuth 2.0, он стыкуется с Google, Facebook и Azure Active Directory. Если вы разрабатываете Web API, берите IdentityServer4 для аутентификации — не ошибётесь.
Так я думал вначале недели. Сегодня четверг, и я у меня только что всё заработало. Почему так долго?
Радужное начало
В интернете есть документация, с помощью которой можно быстро разработать серверный и клиентский код аутентификации.
Кратко процесс выглядит так: создаём ASP.NET Core приложение, устанавливаем пакет IdentityServer4, подключаем готовые модули, конфигурируем и — наслаждаемся работающей аутентификацией.
Первый сценарий, о котором рассказывает руководство — это Client Credentials. В этом сценарии нет даже пользователей, он применяется, когда два независимых сервиса должны безопасно работать вместе.
Решение из этой главы состоит из трёх проектов — IdentityServer, Api и Client. IdentityServer — это приложение Web API, которое отвечает за аутентификацию и умеет создавать токены. Api — веб-приложение, которое отдаёт инофрмацию только доверенному клиенту. Client — консольное приложение, тот самый клиент.
В терминах стандартов OpenID и OAuth Клиент — это программа, а не пользователь.
Вначале клиент должен подключиться к серверу аутентификации и получить токен доступа. Код в статье выглядит так:
И он не работет. После вызова GetDiscoveryDocumentAsync объект disco содержит сообщение об ошибке: Error connecting to http://localhost:5000/.well-known/openid-configuration: Service Unavailable.
Если я захожу по адресу http://localhost:5000/.well-known/openid-configuration, то вижу, что сервис работает и возвращает мне JSON.
Почему же не работает консольная программа?
Первая попытка
Поле HttpResponse.RequestMessage.RequestUri имеет значение http://192.168.7.24/. И, кажется, этот адрес совершенно не похож на http://localhost:5000, который мы видим в коде. 192.168.7.24 — IP-адрес моей машины, но почему вдруг localhost разрешается в него, а не в 127.0.0.1 и куда пропал порт 5000?
Сначала я решил проверить, а прослушивает ли IdentityServer внешний порт. Оказалось, что нет, потому что в настройках явно был указан хост http://localhost:5000.
launchSettings.json
Чтобы сервер прослушивал все интерфейсы IPv4, в качестве applicaitonUri надо указать http://0.0.0.0:5000, а чтобы все интерфейсы IPv4 и IPv6 — http://*:5000.
Chrome показывал мне правильный JSON, а клиент продолжал возвращать ошибку 503 Service Unavailable.
Вторая попытка
Обычно я неплох в Google. Однако, наступил момент, когда весь мой опыт мне не помог. Я придумывал десятки формулировок, пытаясь описать проблему разными способами, но интернет был безмолвен. HttpClient не изменяет переданный ему URI. Точка.
Тогда почему изменяет у меня? Что я сделал не так?
Прозрение
Теперь я знаю, что я сделал не так. Я поменял работу. На старой работе у нас не было файрвола, мы сидели в интернете напрямую. Теперь я работаю в банке и файрвол у меня есть. Его параметры настроены в Windows и Chrome их использует. А HttpClient из коробки — нет.
Чтобы включить прокси, надо добавить к HttpClient обработчик с настроенными параметрами.
Client\Program.cs
Наконец, сервер Api сам обращается к IdentityServer, чтобы узнать, можно ли доверять клиенту. Это другой проект, поэтому мы должны продублировать код обработчика.
Api\Startupcs
Вот теперь консольное приложение показывает мне именно то, что я жду.
Заключение
Как я догадался, что дело в файрволе? Я не помню. Мне бы хотелось поделиться секретом решения нетривиальных задач, но как и в других случаях, я его не знаю. Я просто перебирал в голове разные варианты, пока не наткнулся на очевидный. Я его проверил и он сработал.
Такова работа программиста: делаешь что-то и надеешься, что рано или поздно что-нибудь получится. Странный вывод через тридцать лет работы программистом, не правда ли?
Русские Блоги
IdentityServer 3 и IdentityServer 4
В настоящее время популярная фраза «концептуально совместима», но это верно для Identity Server 4. Концепция та же: это все еще поставщик OpenID Connect, созданный в соответствии со спецификациями, но большинство его внутренних точек и точек расширения изменились. Когда мы интегрировали клиентское приложение с IdentityServer, мы не интегрировали его в реализацию. Вместо этого мы используем спецификации OpenID Connect или OAuth для интеграции. Это означает, что любое приложение, используемое в настоящее время с IdentityServer 3, будет использоваться с IdentityServer 4.
Identity Server предназначен для работы в качестве самостоятельного компонента, который сложно реализовать с помощью ASP.NET 4.x, в то время как MVC по-прежнему тесно связан с IIS и System.Web, что приводит к созданию катаны, предоставляющей компоненты механизма внутреннего представления. Благодаря Identity Server 4, работающему на ASP.NET Core, теперь мы можем использовать любую технологию пользовательского интерфейса и размещать IdentityServer в любой среде, где может работать ASP.NET Core. Это также означает, что теперь мы можем интегрироваться с существующими формами / системами входа в систему для выполнения обновлений.
IUserService Identity Server, используемый для интеграции пользовательских хранилищ, теперь исчез, его заменили на IProfileService И сформировать новую пользовательскую абстракцию хранилища IResourceOwnerPasswordValidator 。
На начальном этапе написания IdentityServer 4 находится на RC5, IdentityServer 3 на v2.5.3, а другая основная версия (v3.0.0) запланирована на будущее. Эта статья была обновлена до IdentityServer 4 v2.0.
Вы можетеDominick BaierизIdentityServer 4 анонс статьиУзнайте больше о причинах IdentityServer 4.
Для нашей начальной реализации мы будем использовать сервис памяти, зарезервированный для демонстрации и облегченной реализации. Позже в этой статье мы переключимся на Entity Framework, чтобы более реалистично представлять производственный экземпляр IdentityServer.
Перед началом кодирования переключите URL проекта на HTTPS. Без TLS вы не должны запускать службу аутентификации. Предполагая, что вы используете IIS Express, вы можете сделать это, открыв свойства проекта, перейдя на вкладку «Отладка» и нажав «Включить SSL». Хотя мы здесь, вы должны использовать сгенерированный HTTPS URL в качестве URL приложения, чтобы при запуске проекта мы начинали с правильной страницы.
Если вы столкнулись с проблемами доверия к сертификатам при использовании IIS Express для разработки сертификатов для localhost, попробуйте выполнить следующие действия.В этой статьеизШаг операции, Если вы обнаружите, что есть проблема с этим методом, не стесняйтесь переключиться в автономный режим (вместо IIS Express, который использует пространство имен проекта для запуска).
Во-первых, нам нужно установить следующие пакеты nuget (в настоящее время написаны для 2.0.2):
Теперь к нашему классу Startup начать регистрацию зависимостей и сервисов подключения.
В вашем ConfigureServices Добавьте следующее в метод для регистрации минимально необходимых зависимостей:
Тогда в вашем Configure Добавьте следующее в метод, чтобы добавить промежуточное ПО IdentityServer в конвейер HTTP:
UseIdentityServer Разрешить IdentityServer начать перехватывать маршруты и обрабатывать запросы.
На самом деле мы можем запустить IdentityServer, который может не иметь пользовательского интерфейса, не поддерживает какую-либо область и не имеет пользователей, но вы уже можете начать использовать его! Просмотр документации OpenID Connect Discovery /.well-known/openid-configuration 。
Документация OpenID Connect Discovery
Документ OpenID Connect Discovery (формально известный как disco doc) доступен у каждого поставщика OpenID Connect для этой известной конечной точки (согласно спецификации). Этот документ содержит информацию о расположении различных конечных точек (таких как конечные точки маркеров и конечные точки конца сеанса), типах авторизаций, поддерживаемых поставщиком, и области действия, которая может быть предоставлена. Благодаря этому стандартизированному документу мы открыли возможность автоматической интеграции.
Вы можетеСпецификация OpenID Connect Discovery 1.0Узнайте больше о документации OpenID Connect Discovery.
Когда вы создаете и используете свой собственный подписанный сертификат, не стесняйтесь использовать самоподписанный сертификат. Этот сертификат не должен быть выдан доверенным центром сертификации.
Теперь, когда IdentityServer запущен и работает, давайте добавим некоторые данные.
Клиенты, ресурсы и пользователи
Во-первых, нам нужно хранить клиентские приложения, которые позволяют IdentityServer, ресурсы, которые могут использовать эти клиенты, и пользователей, которым разрешено их аутентифицировать.
В настоящее время мы используем хранилища InMemory, которые принимают коллекцию соответствующих им сущностей, и теперь мы можем использовать некоторые статические методы для их заполнения.
IdentityServer должен знать, каким клиентским приложениям разрешено его использовать. Я хочу думать об этом как о белом списке, вашем списке контроля доступа. Затем настройте каждое клиентское приложение, чтобы разрешить только определенные операции, например, они могут только запросить возврат токена на определенные URL-адреса, или они могут только запросить определенную информацию. У них есть доступ.
Сфера представляет, что вы можете сделать. Они представляют доступ к области, о котором я упоминал ранее. В IdentityServer 4 область видимости моделируется как ресурс и имеет две формы: Identity и API. Определение ресурсов позволяет вам моделировать область, которая будет возвращать определенный набор утверждений, в то время как область ресурса API позволяет моделировать доступ к защищенным ресурсам (обычно API).
Первые три ресурса идентификации представляют область действия, определенную некоторым стандартным OpenID Connect, который мы хотим, чтобы IdentityServer поддерживал. Например, email Диапазон позволял вернуться email и email_verified Заявление. Мы также создали собственный ресурс с логотипом в виде аутентифицированных пользователей. role возвращение role Заявление.
Быстрые советы, openid Область всегда требуется при использовании потоковой передачи OpenID Connect. Вы можетеСпецификация OpenID ConnectНайдите больше информации об этом.
Настраивая объявления в такой области, мы гарантируем, что эти типы объявлений будут добавлены к любым тегам с этой областью (конечно, если у пользователя есть значение этого типа). В этом случае мы обязательно добавим утверждение о роли пользователя в любой токен с этой областью действия. Секрет диапазона будет использован позже во время самоанализа токена.
Область применения и ресурсы
Области OpenID Connect и OAuth теперь смоделированы как ресурсы и являются самым большим концептуальным изменением между IdentityServer 3 и IdentityServer 4.
offline_access Теперь по умолчанию область запроса токенов обновления поддерживается и разрешена для использования Client Атрибут контролируемой области AllowOfflineAccess 。
В расположении полностью зрелого пользовательского хранилища (такого как ASP.NET Identity) мы можем использовать TestUsers:
Заявка на тему пользователя (или ее подраздел) является ее уникальным идентификатором. Это должно быть что-то уникальное для вашего провайдера идентификации, а не адрес электронной почты. Я указал, что это связано сНедавние уязвимости Azure AD。
Теперь нам нужно обновить наш DI-контейнер этой информацией (вместо предыдущей пустой коллекции):
Если вы снова запустите эту команду и снова получите доступ к документу обнаружения, вы увидите заполненный раздел. scopes_supported и claims_supported Раздел.
Функция OAuth
Чтобы протестировать нашу реализацию, мы можем использовать предыдущий клиент OAuth для получения токена доступа с Identity Server. Это будет использовать процесс Client Credentials, поэтому наш запрос будет выглядеть так:
Это вернет наш токен доступа как JWT:
Если мы перейдем к этому токену доступаjwt.io，Мы видим, что он содержит следующее утверждение:
Теперь мы можем использовать конечную точку самоанализа токена IdentityServer для проверки токена, как если бы мы получали его ресурс OAuth от внешней стороны. В случае успеха мы ответим на утверждение в марке. Обратите внимание, что конечная точка проверки маркера доступа в IdentityServer 4 больше не доступна в IdentityServer 4.
Тип предоставления учетных данных пароля владельца ресурса (ROPC)
Документация IdentityServer также предоставляетРекомендации по использованию типов авторизации владельца ресурса, Не обманывайте себя тем фактом, что этот тип авторизации содержит имя пользователя и пароль, это все же просто авторизация, а не аутентификация. На самом деле в статье и в оригинальной спецификации OAuth 2.0 содержится несколько заявлений об отказе от ответственности, в которых говорится, что этот тип авторизации должен использоваться только для устаревших приложений. Пожалуйста, смотрите мою статьюПочему тип предоставления доступа к паролю владельца ресурса не подходит для аутентификации и не подходит для современных приложенийДля расследования всех ошибок типа ресурса владельца ресурса.
Интерфейс пользователя
До сих пор мы работали без интерфейса, давайте передадимотИспользуйте ASP.NET Core MVCGitHub представляет интерфейс быстрого запуска дляИзмени это.
Чтобы загрузить этот файл, скопируйте все папки в репозитории в проект или используйте следующую команду powershell (опять же, в папке проекта):
Теперь нам нужно добавить ASP.NET MVC Core в наш проект. Для этого сначала добавьте в проект следующие пакеты (если они установлены, вы можете пропустить эту установку Microsoft.AspNetCore.All ）：
Затем добавьте к вашим услугам ( ConfigureServices ）：
Наконец добавлено в конец HTTP-конвейера ( Configure ）：
Теперь, когда мы запустим проект, мы увидим заставку. Да здравствует! Теперь, когда у нас есть пользовательский интерфейс, мы можем начать аутентификацию пользователя.
IdentityServer 4 Быстрый старт заставки пользовательского интерфейса
OpenID Connect
Чтобы использовать OpenID Connect для демонстрации аутентификации, нам нужно создать клиентское веб-приложение и добавить соответствующий клиент в IdentityServer.
Во-первых, нам нужно добавить нового клиента в IdentityServer:
Здесь мы используем неявный тип авторизации OpenID Connect. Этот тип авторизации позволяет нам запрашивать идентификационные данные и токены доступа через браузер. Я назову это самым простым типом авторизации, но он также наименее безопасный.
Теперь нам нужно создать клиентское приложение. Для этого нам понадобится еще один веб-сайт ASP.NET Core, на этот раз с использованием шаблона VS веб-приложения (MVC), но без сертификации.
Чтобы добавить аутентификацию OpenID Connect на сайт ASP.NET Core, нам нужно добавить следующие два пакета на наш сайт (опять же, если вы используете его, вы можете пропустить установку Microsoft.AspNetCore.All ）：
Тогда в нашем ДИ ( ConfigureServices ) В том числе:
Здесь мы говорим нашему приложению использовать аутентификацию cookie для входа в систему пользователя и использовать его в качестве метода аутентификации по умолчанию. Хотя мы можем использовать IdentityServer для аутентификации пользователей, каждому клиентскому приложению по-прежнему необходимо опубликовать свой собственный файл cookie (в своем собственном домене).
Теперь нам нужно добавить аутентификацию OpenID Connect:
Здесь мы говорим нашему приложению использовать наш OpenID Connect Provider (IdentityServer), идентификатор клиента, в который мы хотим войти, и тип аутентификации входа в систему после успешной аутентификации (промежуточное программное обеспечение cookie, которое мы определили ранее).
По умолчанию будет использоваться опция промежуточного программного обеспечения соединения ID /signin-oidc Его URI перенаправления, область запроса openid и profile И использовать implicit Мобильность (требуется только идентификационный токен).
Дальше нам нужно в нашем конвейере ( Configure ) Перед добавлением аутентификации UseMvc ：
Теперь, когда мы запустим это приложение и выберем страницу «Контакты», мы получим неавторизованный 401. Это, в свою очередь, будет перехвачено нашим промежуточным программным обеспечением OpenID Connect, которое перенаправляет 302 на нашу конечную точку аутентификации Identity Server и необходимые параметры.
IdentityServer 4 Quick Start UI экран входа в систему
После успешного входа в систему IdentityServer попросит нас разрешить клиентскому приложению доступ к определенной информации или ресурсам от вашего имени (эта информация или ресурсы соответствуют идентификатору и объему ресурсов, запрашиваемым клиентом). Запрос согласия может быть отключен на клиенте в зависимости от клиента. По умолчанию промежуточное ПО OpenID Connect в ASP.NET Core запрашивает диапазон файлов openid и конфигурации.
Экран согласия интерфейса быстрого запуска IdentityServer 4
Это все, что требуется для подключения простого OpenID Connect Client с использованием неявного типа авторизации.
Entity Framework Core
В настоящее время мы используем его в памяти, как мы упоминали ранее, для демонстрационных целей или, самое большее, для очень легкой реализации. В идеале мы хотим переместить различные хранилища в постоянную базу данных, которая не будет удаляться при каждом ее развертывании, или для добавления новых записей требуются изменения кода.
IdentityServer имеетПакет шнурка Entity Framework (EF), Мы можем использовать его для реализации клиентских, областных и постоянных хранилищ авторизации с использованием любого поставщика реляционных баз данных EF Core.
Программный пакет Identity Server Entity Framework Core был интегрирован протестирован с использованием поставщиков баз данных In-Memory, SQLite (в памяти) и SQL Server. Если вы обнаружите какие-либо проблемы с другими провайдерами или захотите написать тесты для других провайдеров баз данных, пожалуйста, не стесняйтесь открывать проблемы или отправлять пул-запросы на трекер проблем GitHub).
В этой статье мы будем использовать сервер SQL (SQL Express или локальная база данных будут делать это), поэтому нам нужен следующий пакет nuget:
Долговечный магазин подарков
Хранилище постоянной авторизации содержит всю информацию о данном согласии (поэтому мы не всегда будем запрашивать согласие для каждого запроса), ссылаясь на токен (сохраненный jwt, где только ключ, соответствующий jwt, предоставляется запрашивающей стороне, делая Это легко отменить) и многое другое. Без постоянного хранилища токен будет аннулирован при каждом повторном развертывании IdentityServer, и мы не сможем разместить несколько установок одновременно (без балансировки нагрузки).
Сначала сделайте несколько новых переменных:
Тогда мы можем добавить AddIdentityServer Добавьте поддержку для постоянного хранилища авторизации следующим образом:
Хранение клиента и области
Чтобы получить что-то похожее для нас, наша область замены и магазин для клиентов добавляют постоянное хранилище AddInMemoryClients ， AddInMemoryIdentityResources и AddInMemoryApiResources С:
Эти регистрации также включают службы политики CORS, считанные из нашей таблицы клиентов.
Для запуска EF-миграции нам нужно Microsoft.EntityFrameworkCore.Tools Добавьте пакет как инструмент CLI в csproj:
Затем мы можем использовать следующие методы для создания миграции:
Чтобы создать клиентов и ресурсы программно с использованием конфигурации, которую мы использовали ранее, просмотрите этобиблиотекаМетод InitializeDbTestData。
ASP.NET Core Identity
Чтобы добавить постоянное хранилище для наших пользователей, Identity Server 4 обеспечивает интеграцию библиотеки ASP.NET Core Identity (ASP.NET Identity 3). Мы будем использовать базовую библиотеку и основу сущности ASP.NET. IdentityUser Сущность снова использует сервер SQL для выполнения этой операции:
Тогда нам нужно для нашего ConfigureServices Способ добавления регистрации ASP.NET Identity DbContext.
Тогда в нашем IdentityServerBuilder замещать AddTestUsers В:
Нам нужно снова запустить миграцию. Это можно сделать следующими способами:
Это все, что вам нужно для подключения ASP.NET Core Identity к IdentityServer 4, но, к сожалению, ранее загруженный пользовательский интерфейс Quickstart больше не работает, потому что он все еще используется TestUserStore 。
Тем не менее, мы можем изменить наш существующий AccountsController из интерфейса быстрого запуска для замены ASP.NET Core Identity путем замены некоторого кода.
Использовать ExternalCallback Для метода обратного вызова нам нужно заменить логику поиска и предоставления следующим: