HTTP — это протокол без сохранения состояния.После завершения запроса сервер не будет знать, кто отправил запрос в следующий раз (тот же IP-адрес не представляет того же пользователя).В веб-приложениях аутентификация пользователя и мощность аутентификации являются очень важной частью, и на практике существует множество вариантов, каждый со своими достоинствами.
Управление сеансами на основе сеансов
На ранней стадии разработки веб-приложений используется большинство методов управления сеансами на основе сеансов, и логика выглядит следующим образом.
- Клиент использует имя пользователя и пароль для аутентификации
- Сервер генерирует и сохраняет сеанс и возвращает идентификатор сеанса клиенту через файл cookie.
- Когда клиент получает доступ к интерфейсу, требующему аутентификации, SessionID передается в файле cookie.
- Сервер находит сеанс через SessionID и аутентифицирует его, а также возвращает данные, требуемые клиентом.
Есть несколько проблем с сеансовым подходом.
- Сервер должен хранить сессию, а поскольку сессию нужно искать часто и быстро, она обычно хранится в памяти или в базе данных памяти.В то же время, когда много онлайн-пользователей, это занимает много ресурсов сервера.
- Когда требуется масштабирование, сервер, который создает сеанс, может не быть сервером, который аутентифицирует сеанс, поэтому все сеансы необходимо хранить и совместно использовать отдельно.
- Поскольку клиент использует файл cookie для хранения SessionID, в междоменных сценариях требуется обработка совместимости, и этот метод также трудно предотвратить атаки CSRF.
Управление сессиями на основе токенов
Ввиду вышеупомянутых недостатков метода управления сессией сессионного сеанса родился метод управления сессией на основе без гражданства. Так называемое безграждаемое означает, что сервер больше не хранит информацию, или даже больше не хранит сеанс. Логика выглядит следующим образом.
- Клиент использует имя пользователя и пароль для аутентификации
- Сервер проверяет имя пользователя и пароль, а после прохождения генерирует Токен и возвращает его клиенту
- Клиент сохраняет токен и добавляет токен в параметр URL или заголовок HTTP при доступе к интерфейсу, требующему аутентификации.
- Сервер аутентифицируется путем декодирования токена и возвращает данные, требуемые клиентом.
Метод управления сеансом на основе токенов эффективно решает проблемы, вызванные методом управления сеансом на основе сеанса.
- Серверу не нужно хранить информацию, связанную с аутентификацией пользователя. Информация об аутентификации будет зашифрована в токене. Серверу нужно только прочитать информацию об аутентификации, содержащуюся в токене.
- Чтобы избежать проблемы не может быть расширена из-за общего сеанса
- Не нужно полагаться на файлы cookie, эффективно избегая CSRF-атак, вызванных файлами cookie.
- Используйте CORS для быстрого решения междоменных проблем
Введение в JWT
JWT – это сокращение от JSON Web Token. Сам JWT не определяет никакой технической реализации. Он определяет только правило управления сеансом на основе токена, охватывающее стандартный контент, который должен содержать токен, и процесс создания токена.
Токен JWT выглядит так.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1NDQ1MTE3NDMsImp0aSI6IjYxYmVmNjkyLTE4M2ItNGYxYy1hZjE1LWUwMDM0MTczNzkxOSJ9.CZzB2-JI1oPRFxNMaoFz9-9cKGTYVXkOC2INMoEYNNA
Тщательная идентификация покажет, что он состоит изA.B.CThree parts, which in turn is a three-part head (Header), load (Payload), Signature (Signature), and the head load in JSON form, which is in JSON JWT, the contents of all three parts separately after Base64 encoding к.Сращивается с токеном JWT.
Используемый алгоритм шифрования и тип токена хранятся в заголовке JWT.
{
"alg": "HS256",
"typ": "JWT"
}
Полезная нагрузка — это полезная нагрузка. Спецификация JWT определяет некоторые поля и рекомендует их использование. Разработчики также могут сами указывать поля и содержимое, например следующее.
{
username: 'yage',
email: 'sa@simpleapples.com',
role: 'user',
exp: 1544602234
}
Следует отметить, что содержимое полезной нагрузки имеет только кодировку Base64, что эквивалентно хранилищу открытого текста для клиента, поэтому не размещайте конфиденциальную информацию.
Часть Signature используется для проверки того, был ли токен JWT подделан, поэтому эта часть будет использовать секрет для шифрования первых двух частей, логика следующая.
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Преимущества и проблемы JWT
У JWT есть все преимущества управления сессией на основе токена, не зависят от файла cookie, так что оно может предотвратить работу атак CSRF правильно отключить среду браузера Cookie.
Самым большим преимуществом JWT является то, что серверу больше не нужно хранить сеанс, что упрощает расширение бизнеса аутентификации и аутентификации на стороне сервера, позволяет избежать внедрения Redis и других компонентов, которые необходимо ввести для хранения сеанса, и снижает сложность архитектуры системы. Но это также самый большой недостаток JWT.Поскольку срок действия хранится в токене, после выпуска токена JWT он останется доступным в течение срока действия и не может быть отозван на стороне сервера.Когда пользователь выходит из системы, они могут полагаться только на то, что клиент удалит локальное хранилище.Если вам нужно отключить токен JWT пользователя, вы не можете сделать это, просто используя JWT.
Практика на основе JWT
Поскольку JWT по-прежнему имеет много проблем и даже не может удовлетворить некоторые потребности бизнеса, мы все же можем внести некоторые улучшения на практике на основе JWT, чтобы сформировать компромиссное решение.В конце концов, в сценарии управления сеансом пользователя нет серебряной пули.
Упомянутые выше токены - это все токены доступа, то есть токены, необходимые для доступа к интерфейсу ресурса.Есть также еще один токен, токен обновления.При нормальных обстоятельствах срок действия токена обновления будет больше, а срок действия токена обновления токен доступа будет короче. , когда срок действия токена доступа истекает из-за истечения срока действия, используйте токен обновления для получения нового токена доступа. Если срок действия токена обновления также истекает, пользователь может только снова войти в систему.
В практику JWT Refresh Token вводится для улучшения процесса управления сеансом следующим образом.
- Клиент использует имя пользователя и пароль для аутентификации
- Сервер генерирует токен доступа с более коротким сроком действия (например, 10 минут) и токен обновления с более длительным сроком действия (например, 7 дней).
- Когда клиент обращается к интерфейсу, требующему аутентификации, он переносит токен доступа.
- Если срок действия токена доступа не истек, сервер вернет необходимые данные клиенту после аутентификации.
- Если аутентификация завершается сбоем (например, возвращается ошибка 401) при доступе к интерфейсу, требующему аутентификации с помощью токена доступа, клиент использует токен обновления, чтобы применить новый токен доступа из интерфейса обновления.
- Если срок действия токена обновления не истек, сервер выдает клиенту новый токен доступа.
- Клиент использует новый токен доступа для доступа к интерфейсу, требующему аутентификации.
Сохраните сгенерированный токен обновления и время истечения срока действия в базе данных сервера. Поскольку токен обновления не будет проверяться, когда клиент запрашивает бизнес-интерфейс, он будет проверен только при применении нового токена доступа, поэтому токен обновления сохраняется. в базе данных Это не повлияет на время отклика бизнес-интерфейса, и при этом его не нужно хранить в памяти, как Session для обработки большого количества запросов.
Приведенная выше архитектура обеспечивает способ отключить токен пользователя. Когда пользователь должен выйти из системы или отключить пользователь, ему нужно только отключить или удалить токен обновления на сервере. После истечения истечения токена доступа пользователь не может Получить новый. Токен доступа и больше не может получить доступ к интерфейсу, который требует аутентификации. Хотя этот метод будет иметь определенный оконный период (в зависимости от времени истечения токена доступа), в сочетании с работой клиента для удаления токена доступа, когда пользователь выходит из системы, он может в основном соответствовать требованиям точности для аутентификации пользователя под нормальные обстоятельства.
Суммировать
Использование JWT повышает эффективность разработчиков, разрабатывающих аутентификацию пользователей и функции проверки подлинности, снижает сложность архитектуры системы, позволяет избежать большого количества запросов к базе данных и кешу, а также уменьшает задержку ответа бизнес-интерфейсов. Однако эти преимущества JWT также усложняют управление токенами.Внедрив Refresh Token, мы можем продолжать использовать преимущества, предоставляемые JWT, и сделать точность управления токенами соответствующей потребностям бизнеса.