Как проверить и обновить идентификатор токена JWT во время моего СПА-нагрузки?


Я довольно новичок в OAuth 2.0 и OpenID Connect, и мне трудно понять некоторые части потока (или какие лучшие практики я должен использовать)...

Извините за длинный пост :)

Моя Настройка:

  1. OP (поставщик OpenID), который в основном является сервером express, использующим oauth2orize-openid и passport для аутентификации и авторизации пользователей. Давайте назовем это http://authserver.com

  2. A Single page application (react+webpack), который должен аутентифицировать пользователей против моего OP, назовем его http://my-spa.com

Поскольку это SPA (статически обслуживаемый webpack), я должен использовать Implicit Flow.

Мои Вопросы

Как только пользователь переходит к http://my-spa.com, приложение загружается, затем оно проверяет по localStorage, существует ли id_token.

No id_token in localStorage on load:

  1. поскольку маркера нет, я перенаправляю на http://authserver.com/dialog/authorize
    • response_type=id_token
    • scope=openid profile
  2. после успешной аутентификации и авторизации пользователя, authserver перенаправляет обратно на my-spa с помощью id_token во фрагменте URI
  3. я сохраняю id_token в localStorage, и пользователь может начать использовать приложение.

Есть id_token в localStorage на нагрузке

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

Каковы наилучшие методы для этого? Вот то, что я думаю, было бы правильно:

  1. перенаправление на http://authserver.com/dialog/authorize использование :
    • prompt=none
    • id_token_hint=CURRENT_TOKEN
  2. Как только OP получает этот запрос, он должен проверить подпись JWT, попытаться автоматически утвердить пользователя и перенаправить обратно с новым JWT.

Токен get истек через некоторое время

Допустим, у зарегистрированного пользователя истек срок действия JWT, когда он должен запросить новый? Что должно вызвать обновление?

Что такое /tokeninfo или /userinfo за что?

Насколько я понимаю, JWT хранит все данные, необходимые для идентификации пользователя. Однако я видел примеры вызова /tokeninfo или /userinfo.

Если у меня уже есть идентификатор sub, являются ли эти конечные точки только для проверки маркера (предполагая, что мне не нужно ничего, кроме идентификатора субъекта)?

Проверка подписи JWT

Помимо OP, следует ли my-spa проверить подпись JWT (возможно, с открытым ключом)?

Повторное использование этого маркера для доступа к REST API третьей стороны служба

Если у меня есть другой api веб-службы, вызовите его http://my-service.com/api, который должен знать, какой пользователь вызвал его из моего SPA, вот шаги, которые я считаю, что мне нужно выполнить:

  1. добавляем id_token в Bearer для каждого запроса AJAX
  2. my-service.com следует проверить подпись JWT (с открытым ключом?) и решить, разрешить или запретить доступ к защищенному ресурсу

Любая помощь будет оценена по достоинству!

1 2

1 ответ:

Ваш вопрос большой, я постараюсь ответить на все фразы, отмеченные ? в общем виде (без учета конкретных фреймворков, которые вы используете)

В localStorage есть id_token при загрузке.

Пользователь закрыл браузер и снова открыл его. Каковы наилучшие методы для этого?

Вы можете выбрать между оптимизмом и продолжением использования токена или пессимизмом и запросом нового.
  • Продолжайте использовать токен , если время истечения достаточно велико. Я предполагаю, что маркер проверяется в каждом запросе, поэтому, если маркер недействителен, вы получите 401, и вы можете запросить новый

  • Запросите новый токен , если истечение срока действия является коротким или вы хотите потребовать новую аутентификацию пользователя, когда браузер открывает ваше приложение. Если вы хотите проверить, является ли JWT все еще допустимым, перенаправления с auth-сервером не выполняются. удобный для СПА-салона. Я предлагаю, чтобы выполнить AJAX-вызов, чтобы проверить и запросить новый маркер.

Токен get истек через некоторое время

Это первый случай, который я объяснил выше. Вы можете запретить ему выдавать новый токен при каждом запросе или через фиксированные промежутки времени, например через 1 час

Для чего нужны /tokeninfo или /userinfo?

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

Проверка подписи JWT, Рядом с ОП, моя-спа-проверить подпись проверки подлинности (с помощью открытого ключа, может быть)?

Вы должны проверить подпись для каждого запроса. При использовании симметричного ключа (то есть HMAC) JWT подписывается и проверяется с помощью того же ключа. С помощью асимметричных ключей (ОГА), вышлю подписывается с помощью закрытого ключа и проверяется с помощью открытого ключа

Повторное использование этого маркера для доступа к REST API a третья служба

Добавить маркер в качестве маркера для каждого AJAX-запроса,

Правильно, обычно используется заголовок авторизации

My-service.com следует проверить подпись проверки подлинности (с помощью открытого ключа?) и решить, разрешить или запретить доступ к защищенному ресурсу

Конечно, любая служба, использующая JWT, должна проверить подпись. А внешние сервисы не владеют закрытым ключом, поэтому в этом случае требуется использовать ассиметрический ключ. Вы необходимо опубликовать открытый ключ, чтобы внешняя служба могла проверить маркер