Вопрос или проблема
Согласно RFC 6749 строки [scopes] определяются сервером авторизации.
Однако разве это не сервер ресурса определяет области? Я имею в виду, что области отличаются от сервера ресурса к серверу ресурса, не так ли? Даже если они зарегистрированы на одном и том же сервере авторизации.
После некоторого размышления… правильно будет сказать, что сервер авторизации определяет области, а сервер ресурса реализует их.
Клиент запрашивает авторизацию для области, на которую пользователь дает согласие (предоставление авторизации). Затем клиент отправляет предоставление авторизации на сервер авторизации, чтобы получить токен доступа в ответ.
Этот токен доступа должен содержать подписанную область, на которую пользователь дал согласие, что, в свою очередь, значит, что сервер авторизации должен быть осведомлен обо всех областях, которые можно запросить.
Затем дело за сервером ресурса:
-
Проверить этот токен (через конечную точку интроспекции или кэшированный открытый ключ)
-
Разобрать этот токен для получения областей и предоставить/отказать в доступе.
Ответ или решение
Вопрос о том, где определяется область (scope) в контексте авторизации и аутентификации, является ключевым в разработке безопасных систем, использующих протоколы OAuth 2.0. Давайте более подробно разберем, как это функционирует на практике.
Определение области (scope)
Согласно RFC 6749, именно авторизационный сервер отвечает за определение строк, представляющих области доступа. Однако на первый взгляд может показаться, что именно ресурсный сервер имеет наибольшее влияние, так как области доступа могут различаться от одного ресурсного сервера к другому, даже если они зарегистрированы в одном и том же авторизационном сервере.
Роль авторизационного сервера
Авторизационный сервер имеет обязанность не только определять доступные области, но и документировать их. Клиентское приложение запрашивает у пользователя разрешение на доступ к определенным областям, и именно авторизационный сервер является той стороной, которая выдает токены доступа, соответствующие созданным им областям. Эти токены доступа удостоверяют, что пользователь согласился на доступ к определенным ресурсам.
Роль ресурсного сервера
Ресурсный сервер, в свою очередь, конструирует логику доступа на основе таких запросов. Он осуществляет следующие ключевые действия:
-
Валидация токена: Ресурсный сервер должен проверить действительность токена доступа, который был выдан авторизационным сервером. Это может быть сделано через конечную точку интроспекции (introspection endpoint) или с помощью кэшированного открытого ключа.
-
Парсинг токена: После успешной валидации, ресурсный сервер должен распарсить токен для извлечения указанных областей и на основании этой информации принять решение о предоставлении или отказе в доступе.
Взаимосвязь между серверами
Таким образом, можно констатировать, что авторизационный сервер «определяет» области доступа, а ресурсный сервер — «реализует» их. Эта модель делегирует ответственности: авторизационный сервер свои области, а ресурсный — доступ к конкретным ресурсам.
Заключение
В целом, правильный подход к пониманию ролей авторизационного и ресурсного серверов и их взаимодействия является основой для создания безопасных и эффективных систем. Общение между этими компонентами должно быть четко определено, чтобы избежать злоупотреблений и обеспечить безопасность пользовательских данных. Настоящее понимание процесса определения областей и их применения поможет IT-специалистам разрабатывать более надежные, безопасные и интуитивно понятные решения для конечных пользователей.