Используя oAuth 2.0, в "Разрешении на авторизацию" "Разрешить авторизацию", я сначала вызываю "/authorize", получаю код и затем использую этот код в вызове "/token", чтобы получить токен доступа.
Мой вопрос: почему это поток? Я думаю, это из соображений безопасности, но я не могу понять это. Почему реализация такая, и не получить токен сразу после первого вызова ( "/authorize" )?
Зачем нужен этот код для?
Поток кода авторизации предназначен для сценариев, в которых задействованы 3 стороны.
Этими сторонами являются:
Client
Пользователь со своим веб-браузером. Он хочет использовать ваше приложение.
Provider
Имеет информацию о пользователе. Если кто-то хочет получить доступ к этим данным, пользователь должен сначала согласиться.
Ваше (веб-приложение)
Хочет получить информацию о пользователе от поставщика.
Теперь ваше приложение говорит пользователю (перенаправление его браузера в конечную точку /authorize):
Привет, пользователь, вот мой идентификатор клиента. Пожалуйста, поговорите с поставщиком и дайте ему поговорить со мной напрямую.
Поэтому пользователь говорит провайдер (запрашивает код авторизации и возвращает его в ваше приложение, открывая URL-адрес обратного вызова в своем браузере):
Привет, провайдер, я хочу использовать это приложение, поэтому они требуют доступа к моим данным. Дайте мне код, и я приложу этот код к приложению.
Теперь ваше приложение имеет код авторизации, который уже известен клиенту и провайдер. Передав это поставщику , ваше приложение теперь может подтвердить, что доступ к его данным был разрешен клиентом. Поставщик теперь выдает вашему (сетевому) приложению токен доступа, поэтому вашему (сетевому) приложению не придется повторять эти действия каждый раз (по крайней мере на некоторое время).
В случае других типов приложений, где ваше приложение работает непосредственно на стороне клиента (например, приложения iPhone/Android или клиенты Javascript), промежуточный шаг является избыточным.
Может ли быть так, что этот промежуточный шаг не позволяет клиенту видеть токен доступа?
Из книги О'Рейли:
Код авторизации Этот тип предоставления наиболее подходит для серверных веб-приложений. После того, как владелец ресурса авторизованный доступ к своим данным, они перенаправляются обратно в сеть приложение с кодом авторизации в качестве параметра запроса в URL. Этот код должен быть заменен клиентом на токен доступа применение. Этот обмен выполняется между серверами и требует оба client_id и client_secret, предотвращая даже ресурс владелец от получения токена доступа. Этот тип гранта также позволяет долгоживущий доступ к API с помощью токенов обновления.
Неявное предоставление для клиентских приложений на основе браузера Неявное предоставление является наиболее упрощенным из всех потоков и оптимизировано для клиентских веб-приложений, работающих в браузере. Ресурс владелец предоставляет доступ к приложению, и новый токен доступа немедленно отчеканен и передан обратно в приложение с помощью #hash фрагмент в URL. Приложение может сразу извлечь получить доступ к токену из хеш-фрагмента (используя JavaScript) и создать API Запросы. Этот тип гранта не требует посредника 'код авторизации', но он также не делает доступным обновление токены для долговременного доступа.
ОБНОВЛЕНИЕ - да, действительно:
Когда следует использовать код авторизации? Авторизация Поток кода должен использоваться, когда
Long-lived access is required.
Клиент OAuth является сервером веб-приложений.
Ответственность за вызовы API очень важна, и токен OAuth не должен передаваться в браузер, где пользователь может иметь доступ к это.
Подробнее:
Возможно, самое главное - потому что токен доступа никогда не отправляется через браузер - меньше риск, что токен доступа будет просочился в вредоносный код через историю браузера, заголовки реферера, JavaScript и тому подобное.
Данные на стороне клиента обычно считаются небезопасными. В случае неявных вызовов, где токен предоставляется на начальном шаге, любой, у кого есть access_token, может запрашивать данные, API не знает, кто вызывает этот API.
Но в случае приложений веб-сервера, где приложение хочет идентифицировать себя, client_id с client_secret отправляется вместе с authorization_code для получения access_token, который в будущем может быть отправлен независимо.
Предположим, что если access_token первоначально предоставлен сам, тогда как client_id и access_token будут по-прежнему рассматриваться как открытые, поэтому приложение должно будет отправлять client_secret в дополнение к access_token каждый раз, чтобы гарантировать, что запрос действительно исходит от него.
В текущем сценарии после получения access_token дальнейшие запросы могут быть сделаны независимо, не требуя client_secret.
Я думаю, что это так:
Когда мы используем код авторизации, у нас есть две части проверки:
Итак, если мы вернем токен доступа в момент, когда пользователь будет аутентифицироваться вместо кода авторизации, мы знаем, что он запрашивает его, но мы не знаем, что он будет использоваться для зарегистрированного клиента. Так, например, ваш webapp.
Когда мы используем 'implicit grant'; (или возвращаем токен доступа вместо кода авторизации)
Важным моментом является
Возможно, самое главное - поскольку токен доступа никогда не отправляется через браузер - меньше риска того, что токен доступа будет просочиться во вредоносный код через историю браузера, заголовки рефереров, JavaScript и т.п.