Углубленное сравнение OAuth и JWT (веб-токены JSON)

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

Двумя наиболее важными из этих стандартов аутентификации являются OAuth и JWT (веб-токены JSON).

Хотите разобраться в OAuth и JWT? Вы находитесь в правильном месте. В этой статье мы рассмотрим:

• Что такое OAuth, плюсы и минусы его использования

• Что такое JWT (веб-токены JSON), плюсы и минусы

• Как эффективно использовать OAuth и JWT вместе

Давайте погрузимся!

Что такое OAuth?

OAuth (открытая авторизация) — часто записывается как последняя версия OAuth 2.0 — это протокол, который используется для аутентификации пользователя через сервер аутентификации.

Одна из полезных особенностей OAuth заключается в том, что он позволяет вам безопасно делегировать доступ к учетной записи без совместного использования учетных данных. Вместо учетных данных OAuth использует токены доступа.

С помощью токенов доступа клиентское приложение может проверить личность пользователя, прошедшего проверку подлинности.

Визуально процесс выглядит так:

Когда вы реализуете «Войти через Google» или «Войти через Github», вы используете протокол OAuth 2.0!

Плюсы использования OAuth

Работа с OAuth имеет ряд значительных преимуществ, в том числе:

• Это общепринятый отраслевой стандарт. Это означает, что большинство служб аутентификации понимают и используют OAuth 2.0.

• Существует множество вариантов OAuth с поддержкой plug-and-play. Включая такие службы, как «Войти с помощью Google» и «Войти с помощью Facebook», которые уже настроены для использования в вашем приложении.

• OAuth имеет хорошо протестированные клиентские библиотеки практически для всех языков и веб-фреймворков. Это означает, что выбранный вами язык можно использовать с OAuth.

• Это позволяет разделить код. Код вашего клиентского приложения не зависит от кода аутентификации.

• OAuth очень безопасен и проверен в боевых условиях. Из-за его широкого распространения вы можете быть уверены, что все крайние случаи безопасности были продуманы отраслевыми экспертами.

Возможные аспекты использования OAuth

Хотя OAuth — отличный стандарт, при его использовании следует помнить о нескольких вещах:

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

• У него более низкая конфиденциальность конечных пользователей. Сервер авторизации знает все сайты, на которые заходил конечный пользователь. Например, когда сайт использует функцию «Войти через Google», Google сможет отслеживать, когда пользователи этого сайта входят в систему или активны.

• В определенных ситуациях это излишне. Если вы создаете простое веб-приложение с одним интерфейсом и серверной частью, вам не нужен протокол OAuth. Тем не менее, множество онлайн-руководств и готовых решений для аутентификации заставляют вас это реализовать.

• Нет решения для управления сеансами. Как только пользователь аутентифицирован, сервер аутентификации просто возвращает JWT, который может использоваться вашим приложением (как мы увидим позже). Однако после этого шага протокол OAuth не предоставляет никакой поддержки для указания того, как поддерживать аутентифицированный сеанс между интерфейсом и сервером вашего приложения — это полностью зависит от разработчика.

Что такое JWT (веб-токены JSON)?

JWT — это токен, который генерируется сервером аутентификации и содержит информацию о конечном пользователе (например, его идентификатор пользователя, адрес электронной почты и т. д.). Информация представлена ​​в формате JSON и может быть эффективно проверена клиентским приложением с помощью криптографии.

Итак, когда именно уместно использовать JWT?

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

В контексте сервера аутентификации ненадежный клиент — это приложение, которое пытается использовать пользователь. В контексте серверной части приложения ненадежный клиент — это внешний код.

Плюсы использования JWT

Есть несколько веских причин, по которым JWT является таким популярным стандартом:

• Они автономны. JWT может содержать данные пользователя. Таким образом, вам не нужно запрашивать эту информацию у сервера базы данных/аутентификации при каждом запросе.

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

• JWT хранятся только на клиенте. Вы создаете JWT на сервере и отправляете их клиенту. Затем клиент отправляет JWT с каждым запросом. Это экономит место в базе данных.

• Они эффективны и быстро проверяются. Это связано с тем, что JWT не требуют поиска в базе данных.

Возможные аспекты использования JWT

Хотя JWT невероятно полезны, полезно помнить о следующих вещах:

• Вы не можете отозвать их, не прикладывая дополнительных инженерных усилий. Это связано с тем, что при их проверке нет вызова базы данных. Чтобы реализовать немедленный отзыв, вам потребуется [внедрить черный список JWT] (https://supertokens.com/blog/revoking-access-with-a-jwt-blacklist), что может занять много времени.

• Легко создать узкие места в системе безопасности, сохранив при этом один секрет. Если ключ подписи скомпрометирован, злоумышленник может использовать его для создания своих собственных действительных JWT. Это позволит им подделать личность любого пользователя и приложения.

Вместе лучше: как использовать OAuth и JWT вместе

Мы узнали, что OAuth и JWT являются мощными стандартами для построения потоков аутентификации в приложениях. Как оказалось — OAuth против JWT не обязательно должно быть либо — их можно использовать вместе!

Когда сервер аутентификации успешно проверяет учетные данные пользователя (через OAuth), ему также необходимо передать данные пользователя клиентскому приложению. Чтобы клиентское приложение могло проверить детали, можно использовать JWT для обеспечения эффективности процесса.

Это работает, когда сервер OAuth отправляет клиенту JWT (после завершения потока OAuth), содержащий информацию о конечном пользователе.

Типичная полезная нагрузка JSON в JWT, отправляемая сервером OAuth, выглядит следующим образом (пример входа в Google):

```json

"исс": "https://accounts.google.com",

"azp": "1234987819200.apps.googleusercontent.com",

"ауди": "1234987819200.apps.googleusercontent.com",

"sub": "10769150350006150715113082367",

"at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",

"электронная почта": "jsmith@example.com",

"email_verified": "правда",

"иат": 1353601026,

"эксп": 1353604926,

"нонс": "0394852-3190485-2490358",

"hd": "example.com",

Что означают все эти поля? Ниже приведен краткий обзор с использованием этого конкретного примера:

• is: эмитент токена (в данном случае Google)

• azp и aud: идентификаторы клиентов, выданные Google для вашего приложения. Таким образом, Google знает, какой веб-сайт пытается использовать его службу входа, а веб-сайт знает, что JWT был выпущен специально для них.

• sub: идентификатор пользователя Google конечного пользователя.

• at_hash: Хэш токена доступа. Токен доступа OAuth отличается от JWT тем, что это непрозрачный токен. Маркер доступа предназначен для того, чтобы клиентское приложение могло запрашивать у Google дополнительную информацию о вошедшем в систему пользователе.

• email: идентификатор электронной почты конечного пользователя.

• email_verified: подтвердил ли пользователь свою электронную почту.

• iat: время (в миллисекундах с начала эпохи) создания JWT.

• exp: время (в миллисекундах с начала эпохи) создания JWT.

• nonce: может использоваться клиентским приложением для предотвращения повторных атак.

• hd: размещенный домен пользователя G Suite.

Как видите, с сервера OAuth (в данном случае Google) в клиентское приложение передается много информации! Стоит отметить, что некоторые поля в приведенной выше полезной нагрузке JSON относятся к Google (например, hd). Другие провайдеры могут иметь похожий и другой контент.

Поскольку все это находится в JWT, клиентское приложение может проверить содержимое этого JSON и узнать, что этим содержимым никто не манипулировал.

Последние мысли

Часто мы видим, как разработчики спрашивают, использовать ли «OAuth или JWT» для их настройки аутентификации. На самом деле OAuth и JWT — это два разных стандарта с разными вариантами использования, которые можно использовать вместе с большим эффектом. На самом деле JWT часто используется как часть протокола OAuth.

В SuperTokens мы предоставляем решение для аутентификации, которое устраняет большинство недостатков использования OAuth и JWT, в том числе:

• Мы рекомендуем использовать OAuth [только когда это действительно необходимо] (https://supertokens.com/blog/oauth-2-vs-session-management).

• Мы предлагаем способ [легко отозвать JWT / токены доступа] (https://supertokens.com/blog/revoking-access-with-a-jwt-blacklist) без снижения эффективности проверки.

• Мы предлагаем [решение для безопасного управления сеансами] (https://supertokens.com/blog/the-best-way-to-securely-manage-user-sessions), которое является недостающей частью протокола OAuth.

Написано людьми с SuperTokens — надеюсь, вам понравилось! Мы всегда доступны на нашем сервере Discord. Присоединяйтесь к нам, если у вас есть вопросы или вам нужна помощь.