JWT - это строка токена, которая состоит из трех частей, разделенных точкой '.'.
Каждая часть закодирована в Base64 (не зашифрована), поэтому вы можете получить содержимое каждой части с помощью Base64-декодирования каждой части в отдельности. Поскольку данные в кодировке Base64 не содержат символов точки '.', это дает возможность использовать их в качестве разделителя для объединения трех частей в любом случае.
Содержимое трех подстрок, как только JWT был разделен, и каждая отдельная часть декодирована Base64 следующим образом:
- алгоритм, используемый для подписи
- информативное содержимое в JSON формате
- подпись
Таким образом, чтобы получить информацию, полученную от токена, необходимо:
- Разделить JWT на точку
'.' символов - Взять второе часть и
Base64-decode it
Следует учитывать, что информация, содержащаяся в JWT, НЕ защищена чтением, она защищена от модификации; так что нет ничего плохого в возможности декодировать и получать доступ к этой информации без знания сертификатов или ключей шифрования.
Весь процесс, связанный с токеном, состоит из трех участников:
- the эмитент : обычно API аутентификации
- носитель : обычно клиентское приложение API
- потребитель : обычно API, который требует, чтобы он ответил
Третья часть токена, подпись, является элементом, который позволяет потребителю быть уверенным, что токен не был изменен, и по этой причине информация, содержащаяся в ему можно доверять, поскольку он был проверен / предоставлен эмитентом.
От носителя не ожидается, что он сможет проверить токен: ожидается, что он только получит его из процедуры проверки и передаст его API он хочет использовать. В конечном итоге он может получить доступ к содержимому, что означает, что в контексте приложения доступ к информации о токене клиентом, получившим ее , не должен представлять собой уязвимость. Токен должен быть доставлен клиенту (и отправлен обратно потребителю) по защищенному каналу, такому как SSL / https, и это должно защитить доступ к токену другими объектами , а не клиентом, который токен доставляется.
Потребитель и эмитент часто (но не обязательно) просто разные методы API одного и того же приложения.
Алгоритм, используемый для подписи, может быть симметричным c или асимметрия c шифрование один. В первом случае ключ шифрования должен быть разделен между эмитентом и потребителем. Хотя это может показаться проблемой, на самом деле это не так в ситуациях (довольно распространенный случай), когда эмитент также является потребителем (или, по крайней мере, они находятся на одном хосте). В этом случае «общий секрет» действительно никому не передается.
Когда потребитель (один или несколько) должен быть отделен эмитентом, тогда может использоваться асимметричное шифрование c, чтобы эмитент хранит закрытый ключ, а у потребителя просто есть ключ publi c. В этом случае, конечно, также может быть применено симметричное шифрование c, но «общий секрет» должен действительно передаваться различным потребителям, поэтому необходимо выполнить оценки, если это можно безопасно сделать и поддерживать.