как получить токен в js webapp для клиентского бэкэнда только на предъявителя - PullRequest
0 голосов
/ 18 ноября 2018

Я получил эту настройку для моего приложения:

  1. Keycloak server
  2. Бэкэнд nodejs с защитным ключом (только на предъявителя)
  3. Интерфейс PHP / Reactjs

Фронтенд может быть защищен при входе. Для некоторых пользователей потребуется войти в систему, что перенаправит пользователя на сервер Keycloak. После того, как пользователь вошел в систему, у внешнего интерфейса будет токен на предъявителя, чтобы сделать вызовы API к защищенному ключу бэкэнду.

Моя проблема в том, как получить токен на предъявителя для пользователей, которым не нужно входить в систему (анонимные пользователи).

Я попробовал этот подход:

  1. Создан «конфиденциальный» клиент для использования PHP.
  2. Frontend PHP получает токен на предъявителя, используя client_id и client_secret, и передает их в javascript (я имею в виду вывод значений токена внутри тега, который является глобальной переменной)
  3. Первоначально интерфейс делает успешные вызовы API, потому что access_token, переданный php, свежий / действительный.
  4. После истечения срока действия access_token мне нужно будет получить новый, используя refresh_token.
  5. Но для этого мне нужен client_secret, которого нет в приложении js (и, как вы знаете, не рекомендуется сохранять client_secret и пароль в приложении js).

Я застрял здесь. Я исследовал, прочитал много документации, но не смог найти способ достичь этого.

Еще одна идея, которая пришла мне в голову, состояла в том, чтобы сделать носитель access_token долгоживущим (например, 1 час). Но некоторые пользователи могут использовать приложение более часа.

На данный момент, я не уверен, возможно ли совершать анонимные звонки в защищенный бэкэнд-ключ из веб-приложения javascript.

Это неправильно, что очень долго (например, 6 часов) access_tokens? Какие еще варианты у меня есть?

Ответы [ 2 ]

0 голосов
/ 19 ноября 2018

Я сталкивался с подобной ситуацией.Вы можете использовать следующий подход.

  • Ваш API всегда защищен токенами доступа
  • Изначально ваш PHP-бэкэнд получал токен доступа с помощью Client Credentials Grant
  • Как только пользовательский интерфейс загружен, вы делаете JS-вызов в бэкэнд PHP и получаете токен коррелированного доступа.Вы сохраняете его на локальное хранилище
  • Этот вызов защищен сеансом.Изначально это неаутентифицированный / анонимный доступ
  • Если вам нужны токены доступа с разными областями (области, предоставленные только зарегистрированным пользователям, не анонимный случай), то вы заставляете своего конечного пользователя следовать процессу входа в систему для получения новых токенов
  • Как только токены получены, вы снова сохраняете их для сеанса, который у вас есть, с бэкэндом и внешним интерфейсом.
  • Интерфейс может получить токен доступа к внешнему интерфейсу с помощью того же внутреннего вызова
  • токен обновления хранится в бэкенде.Таким образом, безопасно хранить и обновлять
  • Учетные данные клиента никогда не подвергаются внешнему интерфейсу

Единственным бременем является обслуживание сеанса с бэкэндом.Но есть много лучших практик, которые построены вокруг этого.

0 голосов
/ 19 ноября 2018

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

Другой вариант - использовать что-то вроде сеанса для обработки этого, что ДЕЙСТВИТЕЛЬНО увеличивает сложность.https://openid.net/specs/openid-connect-session-1_0.html

...