Проверка подлинности токена для приложений Java

Управление идентификацией здания, включая аутентификацию и авторизацию? Попробуйте Stormpath! Наш REST API и надежная поддержка Java SDK могут устранить риск для безопасности и могут быть реализованы за считанные минуты. Зарегистрируйтесь и никогда больше не создавайте аутентификацию!

Обновление от 5.12.2016: Создание приложения Java? JJWT — это библиотека Java, обеспечивающая сквозное создание и проверку JWT, разработанная нашим собственным Les Hazlewood. Вечно бесплатная и с открытым исходным кодом (Apache License, версия 2.0), JJWT проста в использовании и понимании. Это было разработано с ориентированным на строителя беглым интерфейсом, скрывающим большую часть его сложности. Мы будем рады, если вы попробуете это , и дайте нам знать, что вы думаете! (И, если вы разработчик Node, проверьте NJWT !)

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

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

Аутентификация токена на помощь!

Давайте сначала рассмотрим, что мы подразумеваем под authentication и token в этом контексте.

Аутентификация доказывает, что пользователь — это тот, кем они себя называют.

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

Веб-токены JSON (JWT)

JWT — это URL-безопасная, компактная, автономная строка со значимой информацией, которая обычно имеет цифровую подпись или зашифрована. Они быстро становятся стандартом де-факто для реализации токенов в сети.

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

Строка непрозрачна и может использоваться автономно во многом так же, как и идентификаторы сеанса. Под непрозрачным я имею в виду, что просмотр самой строки не дает никакой дополнительной информации.

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

JWT и OAuth2 токены доступа

Многие реализации OAuth2 используют JWT для своих токенов доступа. Следует отметить, что спецификации OAuth2 и JWT полностью отделены друг от друга и не зависят друг от друга. Использование JWT в качестве механизма токенов для OAuth2 дает много преимуществ, как мы увидим ниже.

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

В дикой природе они выглядят как еще одна уродливая строка:

Если вы посмотрите внимательно, вы увидите, что в строке есть два периода. Это важно, поскольку они разграничивают различные разделы JWT.

Структура JWT

JWT имеют структуру из трех частей, каждая из которых закодирована в base64:

Вот расшифрованные части:

заголовок

требования

Криптографическая подпись

Претензии JWT

Давайте рассмотрим разделы с претензиями. Каждый тип заявки, который является частью спецификации JWT, можно найти здесь .

iss это тот, кто выдал токен.
exp — это когда срок действия токена истекает.
sub является предметом токена. Обычно это какой-то идентификатор пользователя.

Вышеуказанные части формулы изобретения включены в спецификацию JWT. scope не включена в спецификацию, но обычно используется для предоставления информации об авторизации. То есть к каким частям приложения пользователь имеет доступ.

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

ПРИМЕЧАНИЕ. Для сервера по-прежнему крайне важно и всегда рекомендуется проверять действия, предпринимаемые клиентом. Если, например, на клиенте было предпринято какое-то административное действие, вы все равно хотели бы проверить на сервере приложений, что текущий пользователь имеет разрешение на выполнение этого действия. Вы никогда не будете полагаться только на информацию авторизации на стороне клиента.

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

Теперь для большого кикера: безгражданство . Хотя серверу потребуется генерировать JWT, ему не нужно хранить его где-либо, поскольку все пользовательские метаданные кодируются прямо в JWT. Сервер и клиент могут передавать JWT туда-сюда и никогда не сохранять его. Это очень хорошо масштабируется.

Управление безопасностью токенов на предъявителя

Неявное доверие — это компромисс. Эти типы токенов часто называют токенами на предъявителя, потому что все, что требуется для получения доступа к защищенным разделам приложения, — это представление действительного, не просроченного токена.

Вы должны решить такие вопросы, как: Как долго должен быть токен? Как вы отзовете это? (Есть целый другой пост, который мы могли бы сделать на токенах обновления .)

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

Ява, JWT и Вы!

Мы очень гордимся проектом JJWT на Github. Первоначально созданный собственным техническим директором Stormpath, Les Hazlewood , это решение JWT с открытым исходным кодом для Java. Это самая простая в использовании и понимании библиотека для создания и проверки веб-токенов JSON в JVM.

Как вы создаете JWT? Очень просто!

Первое, на что нужно обратить внимание, это API-интерфейс для создания JWT. Вызовы методов объединяются в цепочку, которая возвращает окончательную строку JWT.

Также обратите внимание, что когда мы устанавливаем одну из претензий из спецификации, мы используем установщик. Например: .setSubject("users/1300819380") . Когда настраиваемая заявка установлена, мы используем вызов для указания и указания ключа и значения. Например: .put("scope", "self api/buy")

Так же просто проверить JWT.

Если JWT был каким-либо образом подделан, при анализе утверждений возникнет исключение SignatureException а значение переменной subject останется HACKER . Если это действительный JWT, то из него будет извлечен subject : claims.getBody().getSubject() : claims.getBody().getSubject()

Что такое OAuth?

В следующем разделе мы рассмотрим пример использования реализации OAuth2 в Stormpath, в которой используются JWT.

Существует много путаницы вокруг спецификации OAuth2. Отчасти это потому, что это действительно супер-спецификация — в ней много сложностей. Это также потому, что OAuth1.a и OAuth2 очень разные звери. Мы рассмотрим очень конкретное, простое в использовании подмножество спецификации OAuth2. У нас есть отличный пост, в котором более подробно рассказывается о том, что, черт возьми, такое OAuth . Здесь мы дадим краткий обзор и затем перейдем непосредственно к примерам.

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

Вот и все.

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

Просто помните, что OAuth2 — это протокол для авторизации .

Использование типов OAuth-грантов для авторизации

Давайте посмотрим на типичное взаимодействие OAuth2.

grant_type требуется. Тип содержимого application/x-www-form-urlencoded необходим для этого типа взаимодействия. Учитывая, что вы передаете имя пользователя и пароль по сети, вы всегда хотели бы, чтобы соединение было безопасным. Хорошая вещь, однако, состоит в том, что ответ будет иметь токен-носитель OAuth2. Этот токен будет затем использоваться для каждого взаимодействия между браузером и сервером в будущем. Здесь очень краткая информация, где имя пользователя и пароль передаются по проводам. Предполагая, что служба аутентификации на сервере проверяет имя пользователя и пароль, вот ответ:

Обратите внимание на заголовки Cache-Control и Pragma . Мы не хотим, чтобы этот ответ где-либо кэшировался. access_token — это то, что будет использоваться браузером в последующих запросах. Опять же, нет прямой связи между OAuth2 и JWT. Однако access_token может быть JWT. Вот где появляется дополнительное преимущество закодированных метаданных. Вот как токен доступа используется в будущих запросах:

Заголовок Authorization является стандартным заголовком. Для использования OAuth2 не требуется никаких пользовательских заголовков. Вместо того, чтобы быть типом Basic , в этом случае тип является Bearer . Маркер доступа включается непосредственно после ключевого слова Bearer . Это завершает взаимодействие OAuth2 для типа предоставления пароля. Каждый последующий запрос от браузера может использовать заголовок Authorizaion: Bearer с токеном доступа.

Есть другой тип предоставления, известный как client_credentials который использует client_id и client_secret , а не username и password . Этот тип предоставления обычно используется для взаимодействия API. Хотя идентификатор клиента и секретный секрет работают аналогично имени пользователя и паролю, они обычно имеют более высокий уровень безопасности и не обязательно читаются человеком.

Возьми нас домой: пример Java OAuth2

Мы прибыли! Пришло время покопаться в каком-то конкретном коде, который демонстрирует JWT в действии.

Spring Boot Web MVC

В Stormpath Java SDK есть несколько примеров. Здесь мы рассмотрим пример Spring Boot Web MVC. Вот HelloController из примера:

Ключевая линия для целей этой демонстрации:

Account account = AccountResolver.INSTANCE.getAccount(request);

За кулисами account будет преобразована в объект Account (и не будет null ), ТОЛЬКО если присутствует аутентифицированный сеанс.

Создайте и запустите пример кода

Чтобы построить и запустить этот пример, сделайте следующее:

Запустите пример Spring Boot

Затем вы можете запустить пример Spring Boot следующим образом:

ПРИМЕЧАНИЕ . Предполагается, что вы уже настроили учетную запись Stormpath и ваши ключи API находятся в ~/.stormpath/apiKey.properties . Посмотрите здесь для получения дополнительной информации о быстрой настройке Stormpath с Spring Boot.

Аутентифицироваться с помощью веб-токена JSON (или нет)

Теперь мы можем продемонстрировать пример и показать некоторые JWT в действии! Во-первых, поразите свою конечную точку без какой-либо аутентификации. Мне нравится использовать httpie , но подойдет любой http-клиент командной строки.

Параметр -v производит подробный вывод и показывает все заголовки для запроса и ответа. В этом случае выводится сообщение просто: Hello World! , Это потому, что нет установленного сеанса.

Аутентификация с помощью конечной точки OAuth Stormpath

Теперь давайте oauth конечной точке oauth чтобы наш сервер мог проходить аутентификацию с помощью Stormpath. Вы можете спросить: «Какую oauth точку?» Контроллер выше не указывает ни одной такой конечной точки. Есть ли в этом примере другие контроллеры с другими конечными точками? Нет, здесь нету! Stormpath дает вам готовые (и многие другие) конечные точки прямо из коробки. Проверьте это:

Здесь много чего происходит, поэтому давайте разберемся с этим.

В первой строке я говорю httpie что я хочу создать POST- --form в форме URL — это то, что --form параметры --form и POST . Я использую /oauth/token точку /oauth/token моего локально работающего сервера. Я указываю заголовок Origin . Это необходимо для взаимодействия с Stormpath по соображениям безопасности, о которых мы говорили ранее . Согласно спецификации OAuth2, я передаю grant_type=password вместе с username и password .

Ответ имеет заголовок Set-Cookie а также тело JSON, содержащее токен доступа OAuth2. И угадай что? Этот токен доступа также является JWT. Вот расшифрованные претензии:

Обратите внимание на sub ключ. Это полный URL-адрес Stormpath для учетной записи, с которой я прошел аутентификацию. Теперь давайте снова перейдем к нашей базовой конечной точке Hello World, только на этот раз мы будем использовать токен доступа OAuth2:

Обратите внимание на последнюю строку вывода, что сообщение обращается к нам по имени. Теперь, когда мы установили аутентифицированный сеанс с Stormpath, используя OAuth2, эти строки в контроллере получают имя:

Описание: аутентификация токена для приложений Java

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

Мы дали обзор протокола OAuth2 и рассмотрели подробный пример того, как реализация OAuth2 в Stormpath использует JWT.

Вот некоторые другие ссылки на сообщения об аутентификации на основе токенов, JWT и Spring Boot:

• Аутентификация на основе токенов для Angular.js
• JJWT — веб-токен JSON для Java и Android
• Spring Boot Webapp Пример быстрого запуска
• Спецификация JWT

Управление идентификацией здания, включая аутентификацию и авторизацию? Попробуйте Stormpath! Наш REST API и надежная поддержка Java SDK могут устранить риск для безопасности и могут быть реализованы за считанные минуты. Зарегистрируйтесь и никогда больше не создавайте аутентификацию!