Как клиент должен обрабатывать токен в OAuth2 для принятия решений по графическому интерфейсу

Question

Я очень хорошо понимаю потоки обмена ролями OAuth2 и роли. Что мне неясно, так это то, как оно отображается в сценариях реального мира. Если у меня есть веб-сайт, который действует как часть с графическим интерфейсом (клиент), которая взаимодействует с API остального бэкэнда (поставщик ресурсов), он запрашивает токен с сервера аутентификации для аутентификации в RP. Маркер обычно содержит области описания разрешений или ролей пользователя, которые будут применены RP. Однако GUI обычно должен принимать решения на основе того, какие области / роли были предоставлены токену. С одной стороны это выглядит так, как будто он должен анализировать токен, чтобы выяснить эту информацию, чтобы «адаптировать» пользовательский интерфейс в соответствии с разрешениями пользователя. С другой стороны, токены не обязательно должны быть читаемыми, они могут быть непрозрачными. Похоже, что решения об авторизации принимаются как для клиента, так и для RP, что может указывать на то, что клиент также является вторичным RP? Какой шаблон предназначен для графического интерфейса для получения ролей / областей, к которым пользователь предоставил доступ?

Answer 1

Вы говорите об OAuth2.0 или OIDC или обоих? Вы пометили openid, поэтому я приму оба.

Кажется, решения об авторизации принимаются как на клиенте, так и на клиенте. RP

Клиент OAuth2.0 является проверяющей стороной OIDC. Это одно и то же.

Если вы используете гибридный грант - то есть вы используете OAuth2.0 с OIDC для получения access_token и id_token, тогда ваш id_token будет содержать информацию, которую ваш клиент (проверяющая сторона) может использовать. Это токен JWT, имеющий формат информации, на который вы можете положиться. Это также прозрачно.

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

access_token должен содержать области, связанные с тем, что ваш клиент может получить доступ на сервере ресурсов (ваш бэкэнд API отдыха), тогда как ваш id_token должен содержать утверждения, касающиеся того, кто пользователь, когда и как он аутентифицировался, и любые другие сведения о нем, предоставленные поставщиком удостоверений / сервером авторизации. Эти претензии могут позволить вашему клиенту адаптировать графический интерфейс в соответствии с требованиями.