Подтвердить что ты не робот

Как работает 2-legged oauth в OAuth 2.0?

В OAuth 1.0 2-legged довольно легко: просто отправьте запрос как обычно и опустите заголовок access_token.

В OAuth 2.0 ситуация изменилась (по-моему, сегодня я понял:)). В OAuth 2.0 запрос больше не имеет заголовков, таких как nonce, потребительский ключ, временная метка и т.д. Это просто заменяется на:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

Я понимаю, как работают 3 legged авторизации в OAuth 2.0 и потоки приложений. Но как работает 2-сторонняя работа в 2.0? Возможно ли разработать API, который может поддерживать как двухногий, так и трехногий OAuth 2.0?

Я искал информацию об этом, но я нашел много вещей на 2-legged для 1.0 и почти ничего для 2.0.

4b9b3361

ОТВЕТЫ

Ответ 1

После долгих исследований я обнаружил, что тип гранта client_credentials предназначен для этого сценария. Как только вы введете этот термин в Google, вы найдете множество очень полезных ресурсов.

Это нормальный процесс для 3-стороннего OAuth 2.0 (мы хотим, чтобы пользователь выполнил вход):

Предположим, у нас есть следующие конечные точки в нашем приложении для аутентификации:

/oauth/auth

/oauth/token

Обычно (для предоставления кода авторизации) мы направляем пользователя на /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Затем после аутентификации пользователь перенаправляется на mysite.com/blah?code=somecode

Затем мы получаем somecode и обмениваем его на токен, используя /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

Затем мы можем использовать токен для совершения звонков.

Это поток приложения для client_credentials для реализации двухстороннего OAuth 2.0, который заметно проще:

  • При таком подходе нам не нужно выполнять какую-либо аутентификацию.

  • Мы просто отправляем сообщение /oauth/token со следующими данными формы:

    grant_type=client_credentials&scope=view_friends

Обратите внимание, что область является необязательной. Затем конечная точка напрямую возвращает нам токен доступа (токен обновления не предоставляется). Поскольку токен обновления не предоставляется, по истечении срока действия токена вам потребуется повторно пройти аутентификацию и запросить новый.

Это приводит к следующим оговоркам:

  • Используйте это только для (очень очень) доверенных приложений, таких как внутренние приложения.
  • Вы должны разработать свой собственный способ аутентификации. Например, в RFC-примере используется базовая аутентификация.

Другое решение - использовать JWT (веб-токены JSON), такие как Google OAuth API. Это очень сложный процесс, но существует множество библиотек для генерации вашего JWT. Затем вы публикуете следующие данные формы (конечно же, в кодировке URL):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt

Это сообщение отправлено на /oauth/token для получения вашего токена.

Что касается вопроса , можете ли вы создать API, который поддерживает 2-х и 3-х сторонний OAuth 2.0, да, это возможно.

Тогда конечная точка /auth используется только тогда, когда пользователям необходимо пройти аутентификацию в службе.

В конечной точке /token просто проверьте значение grant_type в параметрах GET для urn:ietf:params:oauth:grant-type:jwt-bearer, если используете JWT или client_credentials для client_credentials.

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

Ответ 2

Вы также можете проверить реализацию Google 2-legged OAuth2 (я считаю, что эта документация была опубликована только недавно).

Google docs docs должен также помочь понять реализацию двухсторонней OAuth2 в Google.