Учитывая ваш контекст, кажется, что OpenId Connect не нужен для вашей ситуации. Это действительно повышает ценность при реализации единого входа (SSO). В этом случае маркер Identity также можно использовать при выходе из системы единого входа.
Наличие дополнительных утверждений о личности в токене доступа также является пустой тратой. Необходимость отправлять всю эту информацию по каждому звонку. Особенно, когда вам нужна информация только один раз (спа может сохранить информацию в памяти). Лучше, чтобы некоторые API (конечная точка) предоставляли информацию по запросу.
Что касается токена доступа, вы не можете его отозвать. Вы можете отменить авторизацию, но токен доступа остается действительным до истечения срока его действия. Вы хотите, чтобы недопустимые токены доступа закорачивались как можно скорее в конвейере, прежде чем оценивать политики.
Обратите внимание, что это не распространенный сценарий, когда API может отозвать доступ, используя внутренний ключ сеанса. Большинство API-интерфейсов являются «безсессионными» и полностью полагаются на токен доступа. Потому что в этом и заключается цель JWT - быть автономным, не связываясь с властью для проверки токена.
Возможно, вы можете использовать долгосрочный токен доступа, потому что в вашей ситуации авторизация определяется на другом уровне. Но способны ли вы определить, когда токен скомпрометирован? И где ты собираешься это проверить? В каждом API и клиенте? Или вы бы предпочли, чтобы власти позаботились об этом (единоличная ответственность)?
При реализации безопасности вы должны посмотреть на дизайн, обязанности, где что делать. Позвольте органу, который выдает токены, позаботиться об аутентификации и авторизации клиента / ресурса. Api, являющийся ресурсом, в котором реализуются бизнес-правила (политики), может позаботиться о (пользователя) авторизации.
Проблема с долгоживущим токеном заключается в том, что когда он попадает в чужие руки, он разрешает доступ до истечения срока его действия или, в вашем случае, до тех пор, пока вы не обнаружите, что что-то не так. Если недолговечный токен всегда позволяет получить доступ на короткое время, то есть хакеру практически не стоит получать токен на время, которое он может быть использован.
С недолговечными токенами доступа вам придется использовать токены обновления. При каждом вызове орган может проверять, должен ли выдаваться новый токен доступа. Конечно, здесь учитывается то же самое, это относится только к ситуации, когда вы фактически проверяете запрос. Токены сами по себе не являются безопасными. Вам придется добавить некоторый уровень безопасности, например, проверьте IP-адрес. Но наличие полномочий позаботиться об этом и использование одноразовых токенов обновления уже повышает безопасность.
По моему опыту работы с oidc / oauth2 токен доступа в основном используется для предоставления клиентским приложениям доступа к ресурсу (от имени пользователя). Где утверждения области определяют доступную функциональность, а подпункты определяют пользователя.
Авторизация может быть реализована на разных уровнях и не должна быть частью токена доступа. На самом деле разрешения вообще не должны быть частью токена доступа.
Так что ваши настройки могут быть в порядке. Но я бы не использовал долгоживущие токены доступа по причинам, уже упомянутым. Плюс они не управляемы. Вы не можете обновить токен доступа при некоторых изменениях в потоке, например, когда добавляется область.