Ответ 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, убедитесь, что у вас есть столбец базы данных для хранения того типа типа предоставления, для которого были сгенерированы идентификатор и секрет. Если требуется иметь несколько типов грантов для каждого пользователя, создайте различный набор учетных данных для каждого типа гранта.