OAuth2 для пользовательского API

Question

Я пытаюсь использовать OAuth2 для API, который я создаю, но могу использовать некоторое объяснение того, как будет работать поток. Я нашел похожие вопросы (например: Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth)), но они не разъясняют, что касается стороннего входа.

Я не хочу использовать OpenID (все равно, в любом случае), особенно если проверка подлинности делегацией может работать нормально. Это кажется чрезмерно сложным и не имеет много хорошо поддерживаемых библиотек. (Я использую PHP + Laravel 4)

Проблема разделяется на 4 (иш) лиц:

• владелец ресурса - Конечный пользователь
• Client - Browser (Мой сайт), мобильный приложение или аналогичное
• Сервер авторизации - Мой сервер OAuth2
• Ресурсный сервер - мой API. Служит пользователям.

Я думаю, что я понял, поток для того, когда пользователь создает учетную запись на моем Идент сервере и использования, на которые приходится войти в систему:

1. Пользователь заполняет имя пользователя/пароль на клиенте.
2. Клиент подключается к серверу Auth, используя поток Владелец ресурса, аутентифицирует пользователя и автоматически разрешает Клиенту.
3. Пользователь перенаправляется с сервера AUth обратно на клиент, с подписанным токеном + JWT, содержащим идентификатор пользователя.
4. Клиент сохраняет токен в сеансе.
5. Клиент использует идентификатор пользователя с идентификатором + подписанный JWT для запроса данных с сервера ресурсов.
6. Сервер ресурсов проверяет JWT и возвращает данные в зависимости от областей токена.

Я еще не протестировал рабочий процесс, но похоже, что это сработает. Однако сторонний логин оказался более сложным. Это то, что у меня есть до сих пор:

1. Пользователь нажимает логин с помощью Google/Facebook/LinkedIn.
2. Пользователь перенаправляется с Клиента на сервер Auth на Google (не мой).
3. Пользователь регистрируется с помощью пользователя/передает и разрешает клиенту получать некоторый защищенный ресурс (userinfo.email). Это аутентифицирует пользователя путем делегирования.
4. Пользователь перенаправляется обратно на Клиент, с подписанным токеном + JWT, содержащим идентификатор пользователя Google.
5. Клиент проверяет JWT.
6. Клиент использует поток учетных данных клиента для подключения к серверу ресурсов. Получает новый токен.
7. Клиент сохраняет токен в сеансе.
8. Клиент просит конвертировать идентификатор пользователя Google в идентификатор пользователя приложения. (Это соединение было сделано во время регистрации.)
9. Сервер ресурсов возвращает идентификатор пользователя приложения. (Подписанный JWT)
10. Клиент использует идентификатор пользователя с идентификатором + подписанный JWT для запроса данных с сервера ресурсов.
11. Сервер ресурсов проверяет JWT и возвращает данные в зависимости от областей токена.

Это может сработать, но это ужасно сложно. Неужели должен быть способ пропустить некоторые из этих шагов? Меня особенно интересует шаг 8-10. Насколько мне известно, пользователь никогда не должен взаимодействовать с моим сервером Auth, используя сторонний логин. Проблема в том, как наилучшим образом подключить успешный id_token (или что-то еще) от Google/Facebook/LinkedIn к ресурсу учетной записи в моем API.

Прямо сейчас, я не беспокоюсь о других клиентах, подключающихся к API, но это то, что произойдет в будущем.

Answer 1

«Насколько я знаю, пользователю никогда не придется взаимодействовать с моим сервером Auth вообще с использованием стороннего входа». Это только отчасти верно. Теоретически, вы можете использовать токен входа сторонней стороны как свой собственный. Поэтому запрос на нормальный ресурс будет:

1. Клиент запрашивает ресурс - отправляет маркер (с 3-го участника) и тип входа в систему (facebook/Google/и т.д.)
2. сервер проверяет запрос, проверяя маркер с 3 участника Сервер авторизации и возвращает данные.

Недостатком является то, что ваш сервер API должен разговаривать с сторонним сервером каждый раз при получении запроса (нужны ли данные из них или нет). Вместо этого, когда вы создаете свой собственный токен, у вас больше контроля и проще проверять запросы.

Я бы придерживался вашего рабочего процесса. Однажды я сделал что-то подобное, и мои шаги были почти такими же. Когда «подсчет» шагов вы также должны учитывать, что для шага 2-4 вам в основном ничего не нужно, так как Google, Facebook и co уже сделали хорошую работу;)

Answer 2

Поздний взнос на ваш вопрос.

Найдено этот ресурс, объясняющий использование OAuth2: OAuth2 in 8 Steps