RESTful API-аутентификация и единый вход с OAuth2 / OIDC - PullRequest
Новая
       19

RESTful API-аутентификация и единый вход с OAuth2 / OIDC

1 голос
/ 02 июля 2019

Представьте себе следующий общий сценарий.У меня есть одностраничное веб-приложение (SPA), которое получает все свои данные с помощью API-интерфейсов RESTful, которые я написал на бэкэнде.

Эти API-интерфейсы также доступны сторонним разработчикам, как и прежде.Мое одностраничное приложение - еще одно из миллионов, использующих API.Сеанс поддерживается в фоновом режиме для удобства аутентификации и кэширования.Сеанс сохраняется через cookie с идентификатором сеанса.

Чтобы использовать API, пользователь должен пройти аутентификацию.Мне нужно поддерживать большой метод SSO (OIDC / OAUTH2) для моего приложения.Очевидно, что мои API должны использоваться программным обеспечением для интеграции, таким как Dell Boomi или обычная SSIS.

Теперь ... давайте поговорим об аутентификации и авторизации.После нескольких дней чтения всего, что я мог на OAuth2 и OpenID, я представляю следующий рабочий процесс.myapp.com настроен на единый вход через Facebook (произвольно):

  1. [Веб-браузер]: GET /customer/1> [Сервер API]
  2. [Сервер API]: Dunno you, chump. 302 redirect here, plz.>[Браузер] https://www.facebook.com/oauth/login?client_id=abcdef&state=12345
  3. [Браузер]: Username: lintlicker, password: iluvcats123> [Facebook]
  4. [Facebook]: Yup, you're someone. 302 redirect here, plz.> [Браузер] https://www.myapp.com/oauth/imback?code=a1b2c3d&state=12345
  5. [Веб-браузер]: json of the stuff from the url> [Сервер API]
  6. [Сервер API]: Here's a code and client-id and client-secret> [Facebook]
  7. [Facebook]: Here's a token to run Facebook APIs for this user ................................

Но, подождите.Я не хочу запускать API Facebook.Я просто хочу аутентифицироваться с помощью Facebook, а затем запустить API моего приложения ... Уже вы можете видеть, что я неправильно понял OAuth по сравнению с OIDC.

Хорошо, тогда Facebook является аутентификатором, использующим OpenID.Но как насчет OAuth для внешнего использования моих API?

Должен ли мой сервер API в основном пересылать OAuth-запрос от браузера / запросчика тому, кто является поставщиком удостоверений?И затем вместо идентификатора сеанса в файле cookie я отправляю обратно токен доступа, срок действия которого истекает, например, через час, а также токен обновления?Тогда браузер отвечает за повторное извлечение токена?

Означает ли это, что браузер или запросчик имеют секрет клиента?Очевидно нет.Так значит ли это, что я должен использовать / поддерживать устаревший метод неявного предоставления ?

Какая здесь хорошая архитектура?

1 Ответ

0 голосов
/ 15 июля 2019

Используя SSO, ваша цель - обеспечить поведение при входе в систему. Для этого вам не нужно полагаться на токен, выданный Facebook. То, что вы можете сделать, это получить данные пользователя из идентификатора токена или вызвать пользовательскую информацию, выставив API-интерфейс провайдера идентификации (например, Facebook), и сохранить их в одном из ваших бэкэндов. Отныне у вас есть возможность поддерживать аутентифицированный статус либо через собственный токен, либо через сеанс.

Что касается других интеграций (от API до API), то для этих интеграций ваш сервер может выдавать токены при успешном завершении потока OAuth (например, - предоставление учетных данных клиента). И если такая интеграция идет с сторонним токеном (например, - Facebook), то ваш бэкэнд может разрешить обмен токенами (плюс регистрация пользователя, регистрация при необходимости).

Недостатком вышеуказанного подхода является требование вашего бэк-энда для обработки этих запросов. Я бы порекомендовал встроить легкий провайдер идентификации, если это возможно. Это должно дать все из коробки.!

...