Оригинальная ссылка:U riot news.com/?is=OAuth2.0…

I. Аутентификация и авторизация

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

А все заботы, связанные с безопасностью, можно разделить на две категории:АутентификацияиАвторизация.

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

Сертификация

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

Однофакторная аутентификация: полагаться только на имя пользователя и пароль
Двухфакторная аутентификация: В дополнение к имени пользователя и паролю также требуется часть конфиденциальной информации (например, веб-сайт банка может потребовать от пользователя ввести PIN-код, который известен только ему)
Многофакторная аутентификация (MFA): Используйте два или более факторов безопасности из разных категорий (например, для больничной системы требуется пароль имени пользователя + код подтверждения безопасности, полученный смартфоном пользователя + информация об отпечатке пальца)

Разрешить

Авторизация относится к процессу проверки того, к чему пользователь может получить доступ. В процессе авторизации уровень разрешений пользователя/приложения определяется до того, как ему будет разрешен доступ к определенным API/модулям. Как правило, авторизация происходит, когда удостоверение пользователяСертификацияпосле.

Авторизация достигается за счет использования «политик» и «правил».

Аутентификация против авторизации

Хотя сертификация и авторизация часто используются как синонимы, попытайтесь понять это с помощью аналогии «содовой и коктейля»: они очень разные — содовая как сырье может быть использована для приготовления многих разных напитков. Ее также можно пить. сам по себе; коктейль представляет собой смесь ингредиентов, газировка может быть одним из них, но не единственным.

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

	Сертификация	Разрешить
1	Определите, за кого себя выдает пользователь	Определить, к каким разрешениям может получить доступ пользователь
2	Аутентификация пользователей с действительными учетными данными	Проверка доступа с помощью правил и политик
3	раньше разрешенного	Выполняется после успешной аутентификации
4	Реализовано с токенами ID	Реализовано с помощью токенов доступа

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

Механизм реализации

Существует несколько способов аутентификации и авторизации, но наиболее популярным в настоящее время является"на основе токенов"Методы.

Что такое аутентификация на основе токенов?

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

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

Что такое токен?

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

Например, это может выглядеть так:cc7112734bbde748b7708b0284233419или более сложные, например:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0NTE5fQ.\-yIVBD5b73C75osbmwwshQNRC7frWUYrqa TjTpza2y4.

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

Зачем использовать токены?

По сравнению с традиционными средствами, такими как файлы cookie, использование токенов имеет следующие преимущества:

нет статуса: токен является автономным и содержит всю информацию, используемую для аутентификации. Это отлично подходит для масштабируемости и освобождает сервер от необходимости хранить сеансы.
можно сгенерировать где угодно: Генерация и проверка токена разделены, что позволяет использовать отдельный сервер или даже другого поставщика для завершения подписи токена, например Auth0 (Аннотация: «Идентификация как услуга» обеспечивает бизнес)
Детальный контроль доступа: С помощью полезной нагрузки токена можно легко указать не только доступные пользователю ресурсы, но и дополнительные роли и разрешения пользователей.

Достичь на основе токенов

Хотя конкретные реализации различаются, в основном они включают следующие шаги:

Пользователь запрашивает доступ через имя пользователя и пароль
Учетные данные для проверки приложения
Приложение выдает подписанный токен клиенту
Клиент сохраняет токен и добавляет его к каждому последующему запросу и отправляет его
Сервер проверяет токен и отвечает данными

Хотя нет никаких ограничений на то, как ваше приложение должно быть реализовано,IETF (Целевая инженерная группа Интернета)Еще определитесь с некоторыми стандартами. Двумя самыми популярными являются:

OAuth 2.0 (RFC 6749 and RFC 6750).
JWT (RFC 7519).

II. Понимание OAuth 2.0

Мы обновили наши знания об аутентификации и авторизации и изучим здравый смысл аутентификации на основе токенов. В этой главе давайте рассмотрим одну из наиболее часто используемых реализаций:OAuth 2.0.

Введение в OAuth 2.0

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

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

OAuth предлагает ввести слой аутентификации для решения этих проблем, и отделить роль клиента (клиента) от роли владельца ресурса. так:

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

OAuth предоставляет клиентам возможность «безопасного доступа к прокси-серверу» для доступа к ресурсам сервера от имени владельца ресурса. OAuth определяет процесс, с помощью которого владельцы ресурсов разрешают третьим лицам доступ к ресурсам своего сервера без предоставления своих учетных данных.

Вот пример для иллюстрации:

Вы знаете "парковочные ключи" для некоторых маленьких автомобилей, верно? Если вы не слышали об этом, есть некоторые модели (Да, экстравагантные! ）附有一种特别的钥匙，可以在泊车时交给服务员。和你的正常钥匙不同的是，这种钥匙不允许汽车开出去一两英里那么远。

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

Точно так же «ключ парковки» в OAuthТокены доступа, через которые разрешены разные уровни доступа к ресурсам.

Терминология OAuth 2.0

Роли: OAuth2.0Спецификация определяет четыре роли.

Владелец ресурса: Сущность, способная предоставлять доступ к защищенным ресурсам. Когда эта сущность является лицом, она представляет конечного пользователя.
Сервер ресурсов: сервер, на котором хранятся защищенные ресурсы и который может принимать и отвечать на запросы защищенных ресурсов с помощью токенов доступа.
Клиент Клиент: Запуск запросов на защищенные прикладные ресурсы, которые представляют владелец ресурсов и проводит свои учетные данные. срок "client" не подразумевает каких-либо характеристик реализации (например, работает ли приложение на сервере, рабочем столе или другом устройстве).
Сервер авторизации: когда владелец ресурса успешно аутентифицирован и авторизован, сервер предоставляет токен доступа клиенту.

Токены: жетонЕсть два типа.

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

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

Выдавать ли токен обновления — на усмотрение сервера авторизации; если да, то он будет использоваться при последующей выдаче токенов доступа.

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

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

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

Понимание этих терминов имеет решающее значение при работе с OAuth 2.0. Итак, попробуйте проиллюстрировать это на примере.

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

Использование метро в качестве метафоры для OAuth

И роль вышеприведенного сценария может выполнять OAuth 2.0 в сочетании со следующим:

Пассажир (клиент) планирую пользоваться метро (защищенный ресурс), поэтому он/она должен спросить билетный автомат или билетную кассу (сервер ресурсов) Купить билет. Билетная система (Сервер авторизации) от имени управления метрополитена (владелец ресурса) С билетом (жетон) для доступа по лицензии.

Управление потоком OAUTH 2.0

Процесс OAuth 2.0 можно представить на следующей схеме:

Варианты использования OAuth 2.0

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

Ниже приведены несколько сценариев, в которых мы попытаемся понять вариант использования OAuth 2.0 на примере носимого устройства.

Возьмем, к примеру, спортивный браслет, предположим, что Алиса его купила, и закончите с соответствующим браслетом в мобильном приложении для отслеживания и анализа движений. Тогда процесс выглядит так?

Сначала Алисе нужно создать профиль в приложении браслета. Один из способов — передать файл приложения, предоставленный для создания форм, другой подход — предоставить приложению-браслету и приложению доступ к другой информации, которая уже хранится там.
Приложение браслета перенаправит вас на экран входа в FriendBook. Как только Алиса успешно войдет в систему со своими учетными данными, она увидит страницу согласия, на которой ее попросят или попросят проверить, какой информацией она должна поделиться и к чему ей разрешен доступ в FriendBook. После подтверждения приложение-браслет может получать и использовать данные из FriendBook с помощью OAuth 2.0.
Носимое устройство отправляет данные в приложение браслета, которое затем синхронизирует данные с сервером для архивирования и анализа.

Секрет клиента: (Хотя следует избегать аутентификации с использованием OAuth 2.0.Алисе не нужно создавать новый пароль, вместо этого она использует пароль, который она уже создала на сервере FriendBook.

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

Пользовательский агент:Приложение браслета играет роль агента своего сервера приложений для синхронизации данных с основным сервером. В связи с этим за счет использования авторизации OAuth 2.0 агентство может точно получить доступ к ресурсам (данным) на сервере.

3. Понимание JWT

Давайте посмотрим на JWT.

JSON Web Token (JWT), обычно читают "jot«Это стандарт, который определяет компактный и автономный объект JSON для безопасной передачи информации между сторонами. Он содержит декларативную информацию, специально для использования в ограниченных помещениях, таких как HTTP; эта информация может быть проверена и доверена потому что он был в цифровом подписании. JWT может быть использован сКлюч (например, HMAC)илиПара закрытых ключей с открытым ключом (RSA или ECDSA)подписать.

Два свойства JWT:

Компактный Компактный:Из-за своего относительно небольшого размера JWT может быть отправлен через URL-адрес, как параметр POST или в заголовке HTTP.
СамостоятельныйJWT содержит всю необходимую информацию о предприятии, чтобы избежать запроса базы данных несколько раз. Акцептор JWT также не должен вызывать сервер, чтобы подтвердить токен.

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

Уведомление: Как следует из названия, JWT находится в формате JSON, что означает, что он содержит пары ключ-значение. Хотя нет ограничений на длину ключей и значений с точки зрения законности JSON и согласованности сторон, большинство стандартов соблюдаются.3 буквыключевой формат.

Терминология JWT

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

AAAAA.BBBBB.CCCCC

Три подстроки называютсяЗаголовок,Полезная нагрузкаиПодпись, объясняются один за другим следующим образом:

Заголовок

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

typ: указывает тип токена (тип), значение равноJWT
alg: указывает алгоритм, подписавший этот токен, напримерHMAC,RSA,SHA

Полезная нагрузка

Вторая часть JWT представляет собой полезную нагрузку, состоящую из утверждений.

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

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

Возможный пример загрузки:

{ 
    "sub": "1234567890", "name": "Alice", "admin": true
}

Объявления в полезной нагрузке можно разделить на следующие три типа:

зарегистрированное заявление

Некоторые заявления зарегистрированы в IANA (D zone.com/refcard/co…) в реестре утверждений веб-токенов JSON. Эти объявления не обязательно использовать или реализовывать во всех случаях, скорее они регистрируются как отправная точка для предоставления полезного набора.

Вот некоторые из вещей, о которых нужно знать:

iss (issuer):Заявление эмитента, являющееся основным выпуском JWT. Это утверждение обычно трактуется в зависимости от специфики приложения. Значение «Iss» — это строка символов с учетом регистра или строка, содержащая обычный URL-адрес. Заявление не является обязательным
sub (subject):Представляет принципала (пользователя) JWT. Значения должны быть либо глобально уникальными, либо локально уникальными в рамках контекста эмитента. Обработка этого утверждения также обычно зависит от приложения. Значение «sub» — это чувствительная к регистру строка, содержащая либо обычную строку, либо URL-адрес. Это объявление является необязательным
aud (audience):Это указывает на целевой получатель JWT. Если, когда в настоящем процессе и заявлении декларации не может быть одним из значений «AUD» для аутентификации самого, оно должно быть отклонено JWT. В большинстве случаев это значение является чувствительным к регистру строевой строке (содержит их общую строку или URL). Это объявление является необязательным
exp (expiration):表示过期时间，即等于或晚于那个时刻再处理 JWT 则绝不可被接受。其值通常是以秒记的时间戳（译注：按 POSIX 中定义的 “seconds since epoch” 标准，也就是 PHP 等语言中常用的那种）。 Это объявление является необязательным
nbf (not before) :Указывает время, прежде чем он никогда не принимается для обработки JWT. Его стоимость обычно является временем в секундах. Это объявление является необязательным
iat (issued at):表示发出 JWT 的时刻。可用于判断 JWT 的寿命。必须是一个时间戳。 Это объявление является необязательным
jti (JWT ID):Предоставьте JWT уникальный идентификатор, значение которого должно быть трудно повторяемым, чтобы предотвратить повторное выполнение JWT. Это объявление является необязательным

публичное заявление

Имена таких утверждений могут быть произвольно определены пользователем JWT. Но для предотвращения конфликтов любые новые имена должны быть зарегистрированы вIANA “JSON Web Token Claims”реестра или определить его как URI, содержащий пространство имен для предотвращения конфликтов, и т. д.

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

Частное заявление

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

подписать

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

Подпись отправителя используется для проверки того, достоин ли JWT этого имени и была ли информация изменена при передаче. Например, если вы создаете токен алгоритмов подписи HMAC SHA256, вы должны сделать что-то вроде этого:

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

более полный пример

Обратите внимание на следующую подпись JWT:

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzYXRpc2giLCJhdWQiOiJteWFwcCIsIkNVU1QiOiIxIiwiZXhwIjoxNTY2MjE0NTg1LCJpc3MiOiJhdXRoLWFwcCJ9.WknG6jiM_vAaflLnKyjlXh5BrM4MUJR9dFrVx-XE3zRVWiyXeIVzI-OomFh0vVHRwrK3-Tttg0HyKBTnCA3mSg

Алгоритм подписи использует кодировку HS512 и включает следующую информацию:

Header: { 
    "alg": "HS512", 
    "typ": "JWT"
} 
Payload: { 
    "sub": "satish", 
    "aud": "myapp", 
    "CUST": "1", 
    "exp": 1566214585, 
    "iss": "my-auth-app"
}

Дело JWT

Сертификация

Когда пользователь успешно входит в систему со своими учетными данными, возвращается токен идентификатора. Согласно спецификации OpenID Connect (OIDC), токен ID является JWT.

Разрешить

После того, как пользователь успешно войдет в систему, приложение может запросить доступ к маршрутам, службам, ресурсам и т. д. от имени пользователя. Для этого используется токен доступа, возможно, в виде JWT. Каждый последующий запрос также включает токен доступа. Поскольку JWT имеет небольшие накладные расходы и может быть легко использован для междоменного доступа, широко используется единый вход (SSO, Single Sign-on).

обмен информацией

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

Зачем использовать JWT?

разъединение

Самым большим преимуществом JWT (по сравнению с управлением сеансом пользователя с использованием случайного токена в памяти) является то, что он позволяет прокси-серверам логики аутентификации стороннего сервера:

Централизованный собственный сервер аутентификации собственной разработки
Как правило, используйте LDAP, коммерческий продукт, который может выдавать JWT.
Можно даже использовать чистого стороннего поставщика аутентификации.

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

нет статуса

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

компактный

JSON, поэтому, когда он закодирован, профиль JWT меньше, чем XML, чем токен SAML. Это делает хорошим выбором JWT, поставляемый в средах HTML и HTTP.

безопаснее

Для подписи JWT может использовать пару открытый ключ/закрытый ключ, которая выражается в форме сертификата X.509. JWT также может быть симметрично подписан путем совместного использования ключа, использующего алгоритм HMAC. Хотя токен SAML также может использовать пару открытый ключ/закрытый ключ, как JWT, но очень сложно подписать XML с помощью алгоритма цифровой подписи XML для Sign JSON.Очень сложно использовать алгоритм цифровой подписи XML.

более общий

Процессоры JSON более распространены в большинстве языков программирования, потому что они напрямую сопоставляются с объектами. Напротив, XML не имеет естественного отображения документа на объект. Это означает, что JWT проще в использовании, чем SAML.

легче обращаться

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

JWT: что следует учитывать

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

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

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

JWT: лучшие практики

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

обеспечить безопасность. Ключ подписи следует рассматривать как любые другие учетные данные и предоставлять только тем службам, которым он необходим.
Не включайте конфиденциальную информацию в полезную нагрузку. Токены подписаны в форме, которой трудно манипулировать и которую легко расшифровать. Добавьте минимальные требования к полезной нагрузке для производительности и безопасности.
Установите срок действия токена. Технически, после того, как токен подписан, он становится постоянным, если не изменяется ключ, используемый для его подписи, или явно не задано время истечения срока действия. Это может вызвать скрытые опасности, поэтому для токенов должна быть стратегия истечения срока действия и отзыва.
Используйте HTTPS. Не отправляйте токены на не-HTTPS-соединения, так как эти запросы могут быть перехвачены и скомпрометированы.
Изучите все варианты использования авторизации. Например, добавление вторичной системы проверки токенов для обеспечения того, чтобы токены генерировались на вашем сервере, может не быть обычной практикой, но может быть необходимо для реализации требований.

Более

Управление доступом на основе ролей с помощью Spring Boot 2 и JWT

--End--

Поиск FemmeLife Подпишитесь на официальный аккаунт

Пожалуйста, укажите источник