JWT. Часть 4 — HS256 и RS256 простыми словами В прошлой части мы разобрали, зачем JWT нужна подпись. Теперь главный вопрос: Кто и каким ключом создаёт эту подпись? Есть два популярных подхода: HS256 RS256 Они решают похожую задачу, но делают это по-разному. HS256 — один общий секрет При HS256 используется один секретный ключ. Например: my-super-secret-key Этим ключом: создают подпись и этим же ключом её проверяют То есть схема такая: Auth Service | | secret key v создаёт JWT А другой сервис для проверки JWT тоже должен знать тот же самый секрет: Order Service | | тот же secret key v проверяет JWT Это называется симметричной схемой. Почему симметричной? Потому что один и тот же ключ используется с обеих сторон. Допустим есть: Auth Service Order Service Payment Service Restaurant Service Если все они должны проверять JWT через HS256, каждому нужен один и тот же секрет. Получается: secret key | +--------------+--------------+ | | | v v v Orders Payments Restaurant И здесь появляется важный нюанс. Если сервис знает секрет, то он потенциально умеет не только: проверять JWT но и: создавать корректно подписанные JWT То есть тот, кто получил этот секрет, получает довольно большие возможности. RS256 — два разных ключа В RS256 используется уже не один ключ, а пара: Private Key Public Key Private Key хранится у сервиса, который выпускает токены. Например: Auth Service Он создаёт JWT и подписывает его приватным ключом. Private Key | v Auth Service | v создаёт JWT А другие сервисы получают только: Public Key И с его помощью проверяют подпись. Например: Auth Service | Private Key | v JWT | +--------------+--------------+ | | | v v v Orders Payments Restaurant | | | +------ Public Key ------------+ И здесь главное отличие. Private Key: может создать подпись Public Key: может проверить подпись Но с помощью Public Key нельзя нормально выпустить новый токен от имени Auth Service. Это особенно удобно в микросервисах. Например: Auth Service единственный хранит приватный ключ. А остальные сервисы: Order Service Payment Service Restaurant Service получают только публичный ключ. Они могут проверить: Этот JWT действительно был подписан нашим Auth Service? Но сами выпустить такой же корректно подписанный JWT не могут. Если провести аналогию: Private Key — это печать организации. Только организация может поставить её на документ. Public Key — это способ проверить, настоящая ли печать. Проверить может много кто. Поставить такую же подпись — нет. Если совсем коротко: HS256 один общий секрет создаёт и проверяет подпись

RS256 Private Key создаёт подпись Public Key проверяет подпись Поэтому в микросервисной архитектуре часто удобнее RS256. Особенно когда один Auth Service выпускает токены, а много других сервисов должны только проверять их. Но подпись — это ещё не всё. Даже правильно подписанный JWT не должен жить бесконечно. Иначе украденный токен можно будет использовать слишком долго. Поэтому в следующей части разберём: Access Token Refresh Token exp и почему access token обычно делают короткоживущим.