Разработчики всё ещё путают JWT, JWKS, OAuth2 и OpenID Connect — разбираем на примерах. Часть 1

[kiberwitch]

Отличная статья! Как раз начал изучать JWT-токены! :)

[northrop]

Еще, насколько помню, есть identity token. Но его смысл при наличии access token от меня ускользает. Можете как-то пояснить?

[meettya]

ID Token (OpenID Connect)

• Purpose: User Authentication (proving identity).

• Recipient: The Client Application (e.g., your frontend).

• Content: User claims (name, email, issuer, etc.) in JWT format.

• Use: Display user info in the UI, manage user sessions.

• Key: Confirms who the user is. 

Access Token (OAuth 2.0)

• Purpose: User Authorization (delegated access).

• Recipient: The Resource Server/API (e.g., your backend).

• Content: Permissions (scopes), not user identity, often opaque to the client.

• Use: Calling protected APIs to get/modify data.

• Key: Grants permission for what the user can do. 

[moguchev]

В следующей части будет разбор)

[meettya]

Благодарю за подробную статью, будем ждать вторую серию. ИМХО основные проблемы тут из-за довольно неудачного нейминга и наличии неочевидных отличий для разных аспектов процесса.

Сама по себе схема взаимодействия, ИМХО, проста, очевидна и совершенно логична.

[grossws]

Неплохая статья. Небольшое замечание: authUser содержит раскрытие информации о существовании пользователя, CWE-208 в общем.

Ну и внезапный RSA256 в комментах, хотя реально используется RS256, естественно.

[moguchev]

Да, вы правы, CWE-208 в чистом виде! Забыл про него)

Можно добавить проверку фиктивного пароля в случае отсутствия user, тогда, по идее, проблемы не должно быть.

[donRumatta]

А как же вы проверяете пароль при таких уникальных солях?

[abushyk]

Обычно такая соль тоже сохраняется недалеко от хешированого пароля.

[moguchev]

Соль хранится рядом с хешированным паролем. Bcrypt хранит соль внутри самой закодированной строки - там хеш пароля, соль и другие параметры. При проверке пароля, берется эта соль, прибавляется к пришедшему паролю, берется хеш и сверяется с эталонным.

[donRumatta]

Ага, спасибо за пояснение. Сомневался, насколько это безопасно класть рядом - но, видимо, считаем, что слишком затратно все таблицы паролей с каждой уникальной солью перехэшировать)

[Masanin]

Жду 2 часть)

[moguchev]

Вышла Часть 2

[hud0shnik]

Коллега, у вас опечатка в ссылке на библиотеку:

Для работы с JWT воспользуемся библиотекой github.com/olang-jwt/jwt/v5 — это фактический стандарт в Go, активно поддерживается и подходит для большинства задач с JWT-токенами. 

В остальном очень хорошая статья, спасибо!

[moguchev]

Спасибо за замечание, исправлено!)

[wanhelsing]

Важное замечание - JWT даёт преимущества только в распределённых системах. Ели вы начинающий разработчик и пилите классическое приложение с одной БД без микросервисов - дополнительная сложность JWT будет только вас тормозить (JWT ≠ безопастность по умолчанию).