Как OAuth обрабатывает авторизацию?

Мы внедрили RESTful API с помощью RestEasy. Теперь мы планируем создать собственную реализацию OAuth и интегрировать ее с нашим Rest API.

Я не совсем понимаю, как OAuth обрабатывает авторизацию каждого запроса к API. Мое понимание заключается в следующем:

  1. Пользователь аутентифицируется сервером OAuth перед выполнением любых вызовов REST API.
  2. Каждый вызов REST API будет содержать токен. Сервер REST API проверяет этот токен на сервере OAuth. Если токен действителен, сервер вернет ответ.

Это должно повлиять на производительность, поскольку мы проверяем токен для каждого запроса API на втором сервере. Верно ли это понимание?


architecture rest performance oauth-2.0
person Sagar Zond    schedule 20.08.2014    source источник
comment
Не надо. Действительно. Если вы не понимаете OAuth и живете и дышите в пространстве безопасности, вы все испортите. Сделать авторизацию правильно сложно. Найдите реализацию поставщика, с которой вы можете жить.   -  person Eric Stein    schedule 20.08.2014

Ответы (1)


arrow_upward
1
arrow_downward

Это будет зависеть от того, как вы определите свой REST API. В основном вызов OAUTH имеет следующие компоненты.

Пользователь: кто делает запрос.

Поставщик: кто хранит информацию о пользователях и предоставляет API для доступа к ним.

Потребитель: кто просит пользователя разрешить потребителю отправлять запросы к API.

Основной рабочий процесс выглядит следующим образом:

  1. Пользователь пытается получить доступ к ограниченному ресурсу от Потребителя.

  2. Потребитель просит пользователя поделиться некоторой информацией о нем.

  3. Пользователь выбирает своего поставщика удостоверений.

  4. Потребитель должен быть известен провайдеру. (Обычно потребитель регистрируется как приложение/веб-сайт на портале провайдера)

  5. Потребитель перенаправляет на провайдера с его Consumer_key и областями.

  6. Пользователь авторизует приложение и предоставляет доступ к какому-то своему ресурсу.

  7. Поставщик создает токен и перенаправляет обратно потребителю.

  8. Потребитель обменивает этот токен и его идентификатор, чтобы получить access_token для пользователя.

  9. Потребитель использует access_token для отправки запроса на авторизацию поставщику и запрашивает мало информации о пользователе.

  10. Поставщик отправляет эту информацию потребителю.

  11. Потребитель проверяет информацию, и пользователь входит в систему.

Теперь каждый токен генерируется в соответствии с областью действия и будет действителен в течение нескольких дней. Проверка токена будет частью ответа от Поставщика.

В вашей системе вы можете хранить пользовательские данные по токену, чтобы нам не нужно было запрашивать у провайдера отправку этой информации. Но если вы не хотите хранить информацию о пользователе, безусловно, будут дополнительные вызовы.

person Manas    schedule 20.08.2014
comment
Мне нужно обработать тайм-аут сеанса и отзыв токена, если я сохранил пользовательские данные против токена. Можем ли мы подключить кэш памяти, такой как источник данных, к серверу Oauth, чтобы мы могли улучшить производительность проверки сеанса. - person Sagar Zond; 20.08.2014