identityserver4 защищать публичный API

Question

Я использую сервер идентификации 4, я следовал руководству, поэтому у меня есть API, клиент MVC, консольный клиент и клиент JS.

Я тоже видел этот блог, который, вероятно, близок к тому, что янужно: https://medium.com/all-technology-feeds/testing-your-asp-net-core-webapi-secured-with-identityserver4-in-postman-97eee976aa16

мне нужен API, где клиенты могут получить доступ к данным, но сначала им нужно пройти аутентификацию.

у нас также есть консольный клиент, который также близок к тому, что мне нужно.

Единственная проблема с этими примерами заключается в том, что в обоих случаях клиент знает секрет.Но в нашем случае несколько клиентов должны использовать один и тот же API-интерфейс, и если у них у всех один и тот же секрет, они могут входить в систему от имени друг друга, но я не хочу иметь разные секреты.

Так чтоЯ думаю, что я мог бы сделать, это создать API, который принимает имя пользователя и пароль, и возвращает токен.Но я не уверен, что это правильный путь?Это похоже на поток владельца ресурса, который не должен использоваться для API, обращенных к клиенту, если я прав.Но в таком случае, как мне это сделать?

спасибо

Answer 1

Кажется, что есть некоторая путаница.Позвольте мне дать краткое резюме.Во-первых, терминология :

• A пользователь - это человек, который использует зарегистрированного клиента для доступа к ресурсам.
• A client - это часть программного обеспечения, которая запрашивает токены у IdentityServer - либо для аутентификации пользователя (запрашивая токен идентификации), либо для доступа к ресурсу (запрашивая токен доступа).Клиент должен сначала зарегистрироваться в IdentityServer, прежде чем он сможет запрашивать токены.

• Ресурсы - это то, что вы хотите защитить с помощью IdentityServer - либо идентификационные данные ваших пользователей, либо API.

• Учетные данные клиента : самый простой тип предоставления и используется для обмена данными между серверами - токены всегда запрашиваются от имени клиента, а не пользователя.

---

Теперь об аутентификации.Клиент запрашивает токены в конечной точке IdentityServer.Когда вы используете клиента в сочетании с клиентскими учетными данными , вам понадобится секрет + клиента.Где секрет действительно секрет и должен быть известен только клиенту.Вы не можете использовать тот же секрет здесь.Кажется логичным по сравнению с пользователями, они также не используют один и тот же пароль.

Это близко к потоку владельца ресурса , однако клиент не может войти в систему как пользователь.Для этого вам понадобится другой поток, например hybrid .В этом случае клиент входит в систему от имени пользователя.Разница заключается в наличии утверждения «sub» (идентификатор пользователя) в токене.

В данном случае клиентом является ваше приложение: console или mvc.Первый поддерживает учетные данные клиента только там, где секрет является обязательным, второй поддерживает гибридный поток, где секретный ключ может быть опущен:

В некоторых ситуациях клиенты должны проходить аутентификацию с помощью identityserver Например,

• конфиденциальные приложения (или клиенты), запрашивающие токены в конечной точке токена
• API, проверяющие эталонные токены в конечной точке самоанализа

Api - это ваш ресурс, который вы хотите защитить.Api никогда не аутентифицирует пользователя или клиента.Это делается IdentityServer.Он только проверяет токен (используя пакет IdentityServer4.AccessTokenValidation).Для этого у него есть свой собственный секрет, который должен быть известен только API.

Чтобы предоставить клиенту доступ к ресурсу, вам необходимо добавить область видимости для клиента в конфигурации IdentityServer.Затем клиенту разрешается (необязательно) запрашивать токен, который предоставляет доступ к ресурсу.

Опять же, API не имеет ничего общего с аутентификацией.Это также не связано с одним клиентом.Несколько клиентов могут получить доступ к ресурсу.Все, что вам нужно сделать, это добавить область действия для каждого клиента, который должен иметь доступ к ресурсу.

Таким образом, в действительности нет ничего против того, что клиенты и ресурсы знают свой секрет.Вам не нужно ничего менять.Все, что вам нужно сделать, это выбрать соответствующий поток.