Кто должен создавать JWT при аутентификации на основе токенов: разработчик приложения или сервер аутентификации? - PullRequest
Новая
       98

Кто должен создавать JWT при аутентификации на основе токенов: разработчик приложения или сервер аутентификации?

0 голосов
/ 10 июля 2020

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

Вопрос

Кто должен нести ответственность за создание JWT, разработчик приложения (через внутренний сервер приложения) или сервер аутентификации (например, поставщик удостоверений)?

(1) Здесь [0] объясняется, что разработчик должен сгенерировать + ha sh JWT и использовать его в качестве токена-носителя для любого запроса. Оттуда сервер аутентификации может использовать общий секретный ключ для проверки токена.

(2) Здесь [1] говорится, что сервер аутентификации генерирует JWT и возвращает его клиент после того, как логин предоставлен + подтвержден (на стороне разработчика не задействован внутренний сервер).

Какой из них правильный? Если они оба верны, как мне узнать, какой из них использовать?

Насколько я понимаю:

(1) # 1 выше - это тот, где разработчик хранит секрет на внутреннем сервере их приложение. Бэкен служит посредником между клиентом и сервером аутентификации для выполнения аутентифицированных запросов без раскрытия секретного + токена доступа.

(2) # 2 выше - это тот, где у приложения вообще нет бэкэнд-сервера ( SPA, такие как Angular / React). Клиент взаимодействует с сервером аутентификации напрямую (без секретов). Согласно [1], IdP использует только идентификатор клиента, область действия и некоторые другие параметры для создания JWT.

[0] https://enable.cx.sap.com/media/1_uup99qpg (переход к 1:49)

[1] https://auth0.com/blog/handling-authentication-in-react-with-context-and-hooks/ (прокрутите вниз до первого блока кода в разделе «Добавить аутентификацию в ваше приложение», где настроен экземпляр Auth0)

1 Ответ

1 голос
/ 13 июля 2020

В зависимости от требований / бюджета / сроков проекта, JWT может быть создан разработчиком или им может управлять третье лицо (например, Auth0).

Термины

Сервер аутентификации

  • Получает учетные данные пользователя (например, имя пользователя и пароль)
  • Проверяет учетные данные пользователя (например, сравнивает хешированный пароль, сохраненный в базе данных, с результат хеширования пароля из запроса)
  • Если токен действителен, сервер отвечает токеном, который используется для аутентификации будущих запросов (часто автоматически сохраняется в cook ie на клиенте, передавая его в правильный заголовок в ответе сервера аутентификации, который затем может автоматически включаться в каждый запрос).
  • Может быть написано с нуля (с учетом большей настройки) или может обрабатываться такими инструментами, как Auth0

Сценарий 1 (SAP)

Этот сценарий включает выполнение аутентифицированных запросов к стороннему API.

  • Ваш интерфейс принимает учетные данные пользователя
  • Ваш бэкэнд ("сервер аутентификации") проверяет учетные данные
  • Ваш бэкэнд отвечает токеном JWT, созданным с использованием ключ RSA от SAP, ваш идентификатор пользователя от SAP и, вероятно, идентификатор пользователя с вашего внутреннего сервера, чтобы вы могли убедиться, что пользователь, отправляющий запрос, авторизован для доступа к запрошенным данным. ПРИМЕЧАНИЕ: Auth0 может использоваться для создания токена, если он поддерживает хранение и передачу пользовательских значений в JWT
  • Ваш интерфейс делает запрос к вашему бэкэнду, включая JWT
  • Ваш бэкэнд обеспечивает авторизацию (можно использовать Auth0, если он поддерживает создание настраиваемых logi c для проверки авторизации ), затем выполняет соответствующий запрос (на основе запроса от внешнего интерфейса) к серверу SAP и передает и JWT, и ключ API (хранящийся на вашем сервере) с запросом
  • SAP проверяет JWT и отвечает вашему бэкэнду запрошенными данными
  • Затем ваш бэкэнд передает соответствующие данные на ваш интерфейс

Сценарий 2 (Auth0) - Демо YouTube

В этом сценарии используется сторонний сервер аутентификации для аутентификации / авторизации маршрутов как на вашем интерфейсе, так и бэкэнд (оба будут использовать инструменты Auth0).

  • Ваш интерфейс направляет пользователя на страницу входа Auth0
  • Auth0 re направляет обратно в ваш интерфейс, где хранится JWT
  • Когда пользователь нажимает кнопку на вашем интерфейсе, которая переводит его на другой маршрут (например, / profile), ваш интерфейс может использовать Auth0, чтобы проверить, есть ли они аутентифицированы / авторизованы и извлекают соответствующие данные пользователя.
  • Когда пользователь нажимает кнопку на вашем интерфейсе, которая делает запрос API на ваш сервер, он отправляет токен JWT с запросом, который ваш бэкэнд использует для аутентификации с помощью Auth0, а затем отвечает соответствующими данными (если пользователь авторизован для их получения).
...