IdentityServer заботится о конфигурации клиентского доступа и аутентификации пользователя, но не об авторизации на уровне клиент / пользователь.
Пользователи не связаны с клиентом. Таким образом, как вы заметили, все пользователи имеют доступ к клиенту. IdentityServer проверяет подлинность пользователя независимо от того, какой клиент используется или входит ли пользователь в IdentityServer напрямую.
То есть клиент (а также API) должен авторизовать пользователя.
Неважно, аутентифицирован ли пользователь (SSO) или нет. Клиент / API отвечает за определение того, авторизован ли пользователь. Чтобы решить эту «проблему», они создали PolicyServer для разделения аутентификации и авторизации.
Добавляя промежуточное ПО (как это сделано в PolicyServer), вы можете предоставить или запретить пользователю доступ.
Вы можете добавить некоторый дискриминатор в IdentityServer, например конкретный тип заявки / роль, используйте отдельный сервер авторизации или используйте авторизацию на основе ресурсов, например, когда (бизнес) пользователь присутствует, то у него есть доступ.
В конце концов, авторизация осуществляется ресурсом, который необходимо защитить, поскольку только ресурс может интерпретировать утверждения и бизнес-правила.
Все, что вам нужно сделать, - это замкнуть трубопровод в случае, если у пользователя , прошедшего проверку подлинности *1017*, нет доступа.
Отлично, если вы хотите «отключить» единый вход. Просто проигнорируйте файл cookie IdentityServer (в клиенте), что вынудит пользователя войти в систему (для этого клиента).
Но вы не должны отказывать в аутентификации (например, возвращать неверный логин), когда пользователь не имеет доступа к клиенту / ресурсу.
Именно поэтому существует http статус 401 Unauthorized и 403 Forbidden. Таким образом, вы можете уведомить пользователя, что он не авторизован для использования этого клиента.
Что касается вашей настройки, в вашем случае вы также можете добавить заявки в таблицу UserClaims (вместо создания дополнительной таблицы) для настройки разрешенных приложений, например, пользователь A:
http://mycompany/appname = app1
http://mycompany/appname = app2
http://mycompany/appname = app3
Добавьте ClaimType в таблицу IdentityClaims и таблицу ApiClaims, чтобы убедиться, что утверждения попадают в токен доступа / идентификации.
Добавьте промежуточное ПО в клиент / ресурс или добавьте бизнес-правила (политики), где вы проверяете тип заявки и требуемое значение. Если нет, то запретить доступ. Например. app1 должен искать требуемый тип заявки http://mycompany/appname со значением 'app1'.