Какое преимущество имеет подпись JWT с RSA по сравнению с SHA в контексте RESTful API?

Question

У меня есть бэкэнд, который предоставляет RESTful API, который в настоящее время «бесплатен для всех» (но использует https).

Теперь я хочу добавить RBA C (управление доступом на основе ролей) и JWT похоже на go, и я много читал о JWT, но не вижу преимущества использования RSA над SHA для подписи токена.

Предполагается, что пользователь прошел проверку подлинности и получил ключ, будь то общий или открытый / личный.

Теперь мне кажется, что в обоих случаях - SHA или RSA HMA C - обе стороны (клиент и сервер) должны иметь общий ключ или свою половину закрытого / publi c ключа в случае RSA. И сервер должен найти этот ключ (в таблице или базе данных) на основе утверждения в JWT, чтобы проверить подпись токена. Как только он подтвердил предполагаемого пользователя в JWT, он авторизует запрос, используя настроенные роли.

Так каковы преимущества RSA в этом сценарии?

Answer 1

Я предполагаю, что вы говорите об алгоритмах RSxxx (например, RSA256) и HSxxx (например, HS256 (HMA C -SHA256)). Основное отличие состоит в том, что HS256 является алгоритмом симметрии c, а RS256 является алгоритмом асимметрии c. Алгоритмы Symmetri c используют только один ключ (или секрет) для подписи и проверки, тогда как алгоритмы asymmetri c используют закрытый ключ для подписи и ключ publi c для проверки токена.

Если вы поделитесь секретом, используемым для HS256, каждый, кто знает секрет, может выдать или изменить и заново подписать токен. Это нарушит цель подписи, если вы поделитесь секретом с клиентом. В случае RS256 или любого другого алгоритма асимметрии c только серверу аутентификации известен закрытый ключ, и любой, кому нужно проверить токен, может использовать для этого ключ publi c. Соответствующий ключ обычно идентифицируется утверждением KID (Key Id) в заголовке токена.

Но обычно подписывание и проверка выполняются только на стороне сервера, клиенту не нужно проверять токен и, следовательно, не нужно знать ключ или секрет вообще. Поэтому вы можете в случае простой службы, когда аутентификация и сервер ресурсов совпадают, по-прежнему полагаться на алгоритмы симметрии c. Но если у вас есть один отдельный сервер аутентификации для нескольких серверов ресурсов, следует использовать асимметрию c algotrithms.

Answer 2

Спасибо за ответ, который помогает прояснить ситуацию.

Так что для простого RESTful API нет никакого реального преимущества в использовании RSA над HSA.

---

Некоторые Точки, которые могут помочь другим в отношении аутентификации на основе токенов:

Преамбула: все это в контексте использования SSL.

Во-первых, токен заменяет учетные данные имени пользователя / пароля: если У клиента есть токен, это эквивалентно имени пользователя / паролю. Мне понадобилось время, чтобы понять это. Это похоже на использование значка на корпоративном принтере: вместо ввода имени пользователя и пароля вы просто помещаете свой значок (токен) на принтер, и он знает, кто вы, и печатает ваш документ.

Однако токены делают использовать API гораздо проще, потому что

• клиент просто добавляет свой токен в заголовок http,
• сервер только проверяет токен,
• также не приходится иметь дело с потоки аутентификации, включающие имя пользователя / pw и управляющие сеансовые куки.

Но недостатком является то, что

• потеря токена подобна потере имени пользователя / пароля и
• в сложной системе, включающей много компонентов, токенов должно быть общим для всех задействованных внутренних серверов.

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

В-третьих, сервер обычно генерирует токен либо на основе доверия клиента, либо после клиента как-то подтвердил подлинность, например. OAuth. После этого клиент просто отправляет токен с каждым запросом, а сервер ищет его в своей таблице. Однако такие серверные таблицы для токенов с произвольной строкой могут становиться большими и должны быть постоянными, поэтому требуется база данных или файл, и они, как правило, сравнительно медленны, требуют обслуживания и т. Д. c, поэтому вводите с помощью криптографии c подписи и jwt:

В-четвертых, токены с подписью:

• сервер подписывает токен и отправляет его клиенту - но сервер также не должен хранить его без файлов cookie сеанса, как описано выше
• клиент надежно хранит токен и отправляет его с каждым последующим запросом (как со случайным строковым токеном)
• сервер получает запрос, вычисляет подпись JWT, и сравнивает его с подписью токена, отправленного клиентом. Обратите внимание, что нет поиска файлов или БД, только вычисление подписи снова и сравнение ее с подписью, отправленной клиентом. Если подписи совпадают, токен должен совпадать с тем, который выдал сервер, и, следовательно, заголовок и полезная нагрузка jwt также совпадают с выданными сервером
• , теперь сервер интерпретирует полезную нагрузку, esp. пользователь (и обычно выполняет авторизацию)

Итак, использование jwt означает, что серверу НЕ требуется

• база данных или файл с именами пользователей и токенами
• для сохранения токенов
• для поддержки сеансовых куки

Необходимо только создать и сравнить подпись. И для этого нужен ключ шифрования c. Это может быть ключ симметрии c для простого API или ключ асимметрии c для более сложных систем, где должны использоваться общие ключи c.

Надеюсь, что это поможет некоторым другим измученным душам, которые столкнулись с это топи c.