Какая гранулярность для областей в OpenId соединяется?

Question

У меня есть провайдер идентификации, несколько клиентских приложений и куча ресурсов API, реализованных в виде сервисов RESTful.Некоторым клиентам нужен один API, другим - несколько API.Также могут существовать «зависимости между API», например, клиенту нужен API X, а API X - API Y.

Какова подходящая гранулярность области в этом случае?Есть ли передовой опыт?

Я могу представить следующие решения:

1. Одна область действия на API: может привести к большим токенам.Кроме того, в приведенном выше примере клиент не знает, что ему действительно необходим API Y.
2. Одна область действия для всех API: это сработает (детализация согласия пользователя не является проблемой).Однако клиент получает сверхмощный токен доступа, который ему фактически не нужен.
3. Одна область на API, но с использованием ссылочных токенов: как решение 1, но токены остаются маленькими.Это приведет к большому количеству вызовов к конечной точке самоанализа.

Answer 1

В крупных корпоративных реализациях с большим количеством приложений мы часто используем URI для областей действия, и они могут быть очень детализированными.CRUD для каждого приложения или API является типичным.

Мы также видим, что некоторые серверы авторизации предоставляют группы CN из LDAP (иногда 50 или более) в качестве областей.

Помните также OAuth 2.0 Инкрементная авторизация . У Google есть активная реализация .