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

задняя часть

Недавно я узнал об аутентификации на основе токенов и поделился ею с вами. Его также используют многие крупные веб-сайты, такие как Facebook, Twitter, Google+, Github и т. д. По сравнению с традиционными методами аутентификации Token является более масштабируемым и безопасным, что очень подходит для использования в веб-приложениях или мобильных приложениях. Токен переводится как "жетон" на китайском языке. Я думаю, что это очень хорошо. Это означает, что вы можете пройти только некоторые уровни с этим жетоном.

Перепечатано с http://ninghao.net/blog/2834.

Традиционные методы аутентификации

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

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

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

Метод аутентификации на основе токенов

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

  1. Клиент запрашивает логин с логином и паролем
  2. Сервер получает запрос на проверку имени пользователя и пароля
  3. После успешной проверки сервер выдаст токен, а затем отправит токен клиенту.
  4. После получения токена клиента его можно сохранить, например, во внутренней или локальной памяти в файле cookie.
  5. Каждый раз, когда клиент запрашивает ресурсы с сервера, ему необходимо принести токен, выданный сервером.
  6. Сервер получает запрос, а затем проверяет токен, переданный в клиентском запросе.Если проверка прошла успешно, он возвращает запрошенные данные клиенту.

JWT

Существует много способов реализовать проверку токена, и есть несколько стандартных методов, таких как JWT, произносится: jot, что означает: JSON Web Tokens. Стандартный токен JWT состоит из трех частей:

  • header
  • payload
  • signature

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

Header

Часть заголовка в основном состоит из двух частей: одна — это тип токена, а другая — используемый алгоритм.Например, следующий тип — JWT, а используемый алгоритм — HS256.

{
  "typ": "JWT",
  "alg": "HS256"
}

Приведенный выше контент должен быть закодирован в Base64, поэтому он выглядит так:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

Полезная нагрузка содержит определенное содержимое маркера. Часть этого содержимого является стандартным полем, и вы также можете добавить другое необходимое содержимое. Ниже приведены стандартные поля:

  • iss: Эмитент, эмитент
  • суб: Тема, тема
  • ауди: Аудитория, аудитория
  • exp: Срок действия, срок действия
  • нбф: не раньше
  • iat: Дата выпуска, время выпуска
  • jti: идентификатор JWT

Например, следующая полезная нагрузка использует эмитента iss и время истечения срока действия. Также есть два настраиваемых поля: одно name , а другое admin .

{
 "iss": "ninghao.net",
 "exp": "1438955445",
 "name": "wanghao",
 "admin": true
}

После использования кодировки Base64 это становится таким:

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

Signature

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

  • header
  • payload
  • secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); 
HMACSHA256(encodedString, 'secret');

После обработки это выглядит так:

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

Окончательный токен, сгенерированный на сервере и отправленный клиенту, выглядит так:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

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

Ссылки по теме

Категории