После долгих исследований я обнаружил, что тип гранта client_credentials подходит для этого сценария. Как только вы введете этот термин в Google, вы сможете найти множество очень полезных ресурсов.
Это нормальный процесс для трехэтапного 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, который заметно проще:
Обратите внимание, что область не является обязательной. Затем конечная точка напрямую возвращает нам маркер доступа (маркер обновления не предоставляется). Поскольку токен обновления не предоставляется, по истечении срока действия токена вам потребуется повторно пройти аутентификацию и запросить новый.
Это приводит к следующим предостережениям:
- Используйте это только для (очень-очень) доверенных приложений, таких как внутренние приложения.
- Вам нужно разработать свой собственный способ аутентификации. Например, в примере RFC используется базовая авт.
Другим решением является использование JWT (веб-токенов JSON), таких как Google OAuth API. Это очень сложный процесс, но существует множество библиотек для создания вашего JWT. Затем вы публикуете следующие данные формы (конечно, в кодировке URL):
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt
Это отправлено на /oauth/token, чтобы получить ваш токен.
Что касается вопроса о том, можно ли создать API, поддерживающий двухсторонний и трехсторонний 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, убедитесь, что у вас есть столбец базы данных для хранения того, для какого типа гранта были сгенерированы идентификатор и секрет. Если требуется иметь несколько типов грантов для каждого пользователя, создайте разные наборы учетных данных для каждого типа грантов.
person
F21
schedule
10.01.2013
