Попытка понять поток OAuth2

Итак, я реализую провайдера с OAuth2.

Я получаю ту часть, где клиент обращается к client_id и client_secret. Это однозначно идентифицирует их у поставщика.

Итак, теперь, когда у них есть это, и они переходят через SSL, зачем нужен токен авторизации? И затем, после этого, зачем нужен код авторизации?

Кроме того, почему токен обновления?

Почему мы не можем просто пойти с client_id и client_secret? Я получаю, что для ресурсов, защищенных на основе авторизации конечного пользователя, требуется дополнительная авторизация. Это имеет смысл. но почему аутентификационный токен и код?

Наконец, все это необходимо для ресурсов, которые не защищены конечным пользователем?

Итак, я думаю, что 5 различных вопросов, которые помогут мне понять:

  1. Почему аутентификационный токен?
  2. Почему код auth?
  3. Зачем нужен токен обновления?
  4. Почему бы просто не использовать учетные данные клиента для незащищенных ресурсов (или мы можем)?
  5. Почему и токен, и код? (Я думаю, на это могут ответить как 1, так и 2).
+1
источник поделиться
1 ответ

Извините за некропостинг, я надеюсь, что это будет полезно кому-то для дальнейшего использования.

Сначала они называются Authorization Code и Access Token.

  1. Access Token - это строка, представляющая право доступа к ресурсу
  2. Authorization Code представляет собой авторизацию, предоставленную Владельцем ресурса Клиенту. В большинстве случаев владелец ресурса является конечным пользователем, которому принадлежат некоторые ресурсы на сервере. Клиент хочет получить доступ к этим ресурсам, поэтому ему требуется авторизация от пользователя.
  3. Refresh Token используется для обновления истекших Access Tokens. Usualli Access Token имеет срок службы в несколько минут, а Refresh истекает через месяцы/годы/независимо. Вы используете доступ; когда они становятся старыми, вы используете токен обновления, чтобы получить новые токены доступа. Обратите внимание, что в OAuth1 был только один тип токена, который длился и в течение нескольких месяцев. Для повышения безопасности протокола были введены токены с коротким замыканием.
  4. Думаю, я не остановился. Если ресурсы не защищены, просто не используйте OAuth! Во всяком случае, существует Грант Credential Client, который используется, если вы считаете, что Клиент является Владельцем ресурсов (здесь пример.
  5. См. 1. и 2. Они разные, и их можно отправить через два разных канала (но я все еще не нашел использование разных каналов).

Короче говоря, когда у Клиента есть Авторизационный код, он говорит серверу авторизации (AS): "ehi, владелец ресурса сказал, что я могу получить доступ к ресурсам!" и AS дает клиенту токен доступа. Теперь, когда у него есть токен, Клиент переходит к серверу ресурсов: "Сервер авторизации сказал, что я могу получить доступ к ресурсам, посмотреть мой токен", и он получает ресурс.

Обратите внимание, что есть 4 потоков, каждый использует другой тип авторизации Гранта и только один из них является кодом авторизации. Все это по словам. О механизме, сначала прочитайте это (немного устаревшее) введение и чем снова прочитайте RFC 6749, помните об этом.

Надеюсь, теперь у вас есть более ясная идея.

+3
источник

Посмотрите другие вопросы по метке или Задайте вопрос