Пишу API для сервиса, клиентами которого будут мобильные приложения (свои + сторонние). Для своих приложений использую
Resource Owner Password Credentials Grant из официальной документации по oAuth 2.0.
Т.е. в приложении делается стандартная форма регистрации (введите email, пароль), затем отправляется на сервер (POST /users), где создается аккаунт пользователя. Далее на endpoint вроде /auth отправляется:
grant_type=password
username=Mike
password=123
client_id=123
client_secret=123
client_id и client_secret не соответствуют спецификации oAuth, но они необходимы для идентификации клиента.
Если все верно, возвращаем токен (в моем случае JWT + refresh_token). refresh_token сделал вечный и использую только для того, чтобы была возможность ручного отзыва.
Здесь все относительно понятно и неплохо соответствует официальной спецификации oAuth.
Далее задача усложняется. Нужна возможность для пользователей регистрации через соцсети. Регистрацию организовал следующим образом: нативное приложение запрашивает доступ к персональной информации и получает токен соцсети, затем отсылает на сервер (POST /users):
social_provider=facebook
social_token=ТОКЕН_ФЕЙСБУКА
Далее сервер по предоставленному токену получает всю необходимую информацию о юзере из соцсети и создает аккаунт. Есть ли смысл сохранять этот токен фейсбука?
И теперь нам надо как-то реализовать выдачу токена нашего API для таких юзеров, зарегистрированных через соцсети. Понятно, что такие аккаунты не имеют паролей, и использовать Resource Owner Password Credentials Grant в чистом виде не выйдет. Как быть? Мысли крутятся в сторону отправки фейсбучного токена в качестве пароля. По нему сервер узнает facebook_id юзера и сможет проверить, есть ли такой юзер в БД. И, соответственно, выдать свой токен.
grant_type=password
username=facebook_user
password=ТОКЕН_ФЕЙСБУКА
client_id=123
client_secret=123
Подскажите, нет ли способов лучше, либо каких-то изъянов в такой схеме?
Простой
