Поток OAuth 2.0 для групп пользователей / организаций

Question

Протокол OAuth 2.0 обеспечивает делегирование разрешений пользователю, чтобы сторонние приложения могли работать от его имени. Типичный способ, которым это делается в потоке OAuth, - это запрос согласия пользователя на одобрение или отказ в доступе для приложения ( пример Okta). Вот официальная спецификация, описывающая, как это работает в общих концепциях.

Я ищу стандартизированный подход для выполнения того же потока, но для групп пользователей (например, организаций). GitHub каким-то образом делает это для организаций, поэтому похоже, что организации представляют собой всего лишь группу учетных записей пользователей. Есть ли стандартизированные подходы к этой проблеме?

Если нет, возможно, есть какие-либо рекомендуемые способы, как это обычно делается архитектурно или может соответствовать протоколам OAuth 2.0/OpenID Connect.

Answer 1

Протоколы OAuth 2.0/OpenID Connect не охватывают, как осуществляется контроль доступа.

В протоколах OAuth 2.0/OpenID Connect вы можете передавать области OAuth или использовать данные конечной точки информации о пользователе OIDC, чтобы сервер ресурсов мог определять контроль доступа.

Многие коммерческие продукты в этой области позволяют использовать LDAP в качестве серверной части для аутентификации и даже преобразуют группы LDAP в области.

Я бы предположил, но я не знаю, что GtHub хранит данные со ссылкой (например, группой) для организации и / или пользователя. Я знаю, что GitHub предоставляет это с помощью областей действия OAuth.

О, и спецификация OAuth находится по адресу: https://oauth.net/2/. Но если вам требуется аутентификация пользователей, вам необходимо использовать OpenID Connect, который построен поверх OAuth 2.0. Помните, что " OAuth 2.0 НЕ ЯВЛЯЕТСЯ протоколом аутентификации "

-Джим

Answer 2

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

Однако вы должны быть в состоянии выразить область высокого уровня, которую вы можете представить пользователю.

С точки зрения авторизации на основе организаций пользователя здесь может быть полезен метод кеширования претензий:https://authguidance.com/2017/10/03/api-tokens-claims/

То есть: * Используйте OAuth для идентификации пользователя и проверок высокого уровня "Затем выполните настоящую авторизацию на основе ваших внутренних данных.

Answer 3

Я делаю здесь некоторые предположения, но считаю, что проблема возникает из-за попытки аутентифицировать сразу две вещи.

Если организация - это то, что вам нужно, тогда создайте поток для аутентификации организации как основного субъекта (через пользователя, имеющего к ней доступ), вместо фактической аутентификации самого пользователя.

После того, как токен доступа сгенерирован, вам не обязательно больше знать, какой пользователь его сгенерировал (или, по крайней мере, сам токен не должен знать). Если вашему пользователю необходимо иметь возможность просматривать и / или отзывать токены доступа, они все равно должны иметь возможность это сделать, поскольку у них есть доступ к организации в вашем приложении.