Я не уверен, что именно вы хотите знать, поэтому я постараюсь ответить на него более широко.
Допустим, у вас есть один поставщик аутентификации (OAuth2), несколько приложений (клиентов), использующих егои несколько пользователей.
Если клиент получает идентификационный токен, токен должен использоваться только для проверки подлинности пользователя клиентом, который его запросил. Идентификационные токены содержат поле aud (аудитория) с клиентским client_id..
Если клиент получает токен доступа, авторизованный владельцем ресурса, он может использовать токен доступа для доступа к любому ресурсу (службе API), который принимает токены, выпущенные поставщиком авторизации.Но служба API проверяет, содержит ли маркер доступа области, необходимые для службы.Если клиент запрашивает область, которую владелец ресурса не может делегировать (недостаточно прав), поставщик аутентификации может вернуть ошибку invalid_scope или просто пропустить область из токена доступа.Решение о том, может ли клиент делегировать область, зависит от реализации поставщика проверки подлинности ( OAuth2 RFC не охватывает ее).
Если вы хотите ограничить некоторые комбинации пользователь / клиент,так что пользователь не может авторизовать клиента для получения токена, опять же, это деталь реализации вашего провайдера аутентификации.
Если ваш вопрос больше о том, что разрешено делать аутентифицированному пользователю в приложении, которое имеет егоИдентификационный токен (или токен доступа), тогда вам решать, как это сделать.Приложения обычно должны ограничивать доступ к службам и данным.Сервисы, как правило, статичны, и доступ может быть основан на областях маркеров доступа.Но данные приложения являются динамическими, и доступ обычно основывается на списках владения данными или управления доступом (ACL - как в файловых системах).