Что такое token пользователя
Токены vs Пароли
Пост навеян недавней темой про токены, в комментариях к которой царила некоторая неразбериха. Я сделал вывод, что многие не до конца понимают или даже вообще не понимают, что такое токен, с чем его едят и чем токен не является. Желание расставить все точки над i привело к написанию нижеследующего текста. Далее речь пойдет именно о USB-токенах, которые можно подключать к компьютеру, давать команды и получать результаты их выполнения. Приступим.
Аспекты хранения информации на токенах
Сразу хочется пояснить, что токен – это не флэшка. Конечно, он может хранить некоторое количество информации, но весьма ограниченное, например, 64 Кб. Существуют токены, которые содержат в себе флэш-память на несколько Гб. Однако данные хранятся в этой флэш-памяти при помощи той же самой технологии, что и на обычной флэшке. Поэтому функцию хранения больших объемов данных можно расценивать как второстепенную или побочную.
Можно сказать, что первоначальная функция токенов – это не извлекаемое хранение ключевой информации. Очевидно, с флэшкой общего мало. Что значит «не извлекаемое»? Это значит, что ключ из токена никогда не попадает никуда извне, например, в оперативную память компьютера. Данную строгую политику можно ослабить до того, что разрешается экспорт ключа из токена в оперативную память только в зашифрованном виде. Также существует опция экспорта ключа в открытом виде. Но даже при выборе владельца токена использовать только эту опцию, уровень безопасности все равно выше, чем хранение ключа на обычной флэшке. Выше он потому, что для экспорта ключа требуется знание PIN-кода, а для копирования ключа с флэшки PIN-код не требуется. Многие скажут: так можно же хранить ключ на флэшке и шифровать его паролем при помощи, например, RAR-а, и токен не нужен! Но, чтобы перебрать все пароли к архиву у нарушителя будет сколь угодно большое количество попыток, а токен после трех последовательных попыток ввода неверного PIN-а блокируется. Вывод: даже при самых скромных настройках безопасности хранить ключ на токене безопаснее, чем на флэшке. С хранением ключей все.
Другие функции токена
Что ещё умеет делать токен? Токен может самостоятельно:
1. Шифровать\расшифровывать в соответствии с алгоритмами симметричного и асимметричного шифрования
2. Генерировать ключи шифрования
3. Формировать и проверять ЭЦП
4. Хешировать данные и т.д.
Токен представляет собой некий «черный ящик» во время осуществления криптографических операций: данные поступают на вход, преобразуются с помощью ключа и передаются на выход. Его можно сравнить с микрокомпьютером. Ввод и вывод информации для токена происходит по USB, есть свой процессор, оперативная и защищенная долговременная память.
Для чего нам нужны пароли?
Для большинства из нас повсеместное использование паролей стало стандартом «де факто» или, если угодно, классикой современности. Хотим аутентифицироваться на почте или соцсетях – легко, зашифровать файл RAR-ом – пожалуйста. Главное преимущество паролей в простоте их использования. Однако, такие вопросы как забывчивость, передача по незащищенным каналам (теще по телефону), набор пароля на клавиатуре, предсказуемость и т.д. ставят под сомнение некоторые важные с точки зрения безопасности операции.
Если сравнивать пароль с криптографическим ключом, то выводы напрашиваются весьма неутешительные. В ГОСТ 28147-89 длина ключа составляет 256 бит (32 байта). При использовании генератора псевдослучайных чисел, ключ обладает хорошими статистическими свойствами. Пароль же, который является, например, словом из словаря, можно свести к псевдослучайному числу длиной 16 бит, что короче ГОСТ-ового ключа в 16 раз. Это сравнение само по себе представляет по криптографическим понятиям полный и безоговорочный fail!
Мое утверждение состоит в следующем: токены способны решать все те задачи, для которых сейчас применяются пароли. Все без исключения. И решать их более качественно и безопасно. Считаю, давно пора заменить схемы на паролях на полноценные криптографические протоколы с ключами. И в этом деле, лучшего помощника, нежели токен, не найти. Чтобы не быть голословным, рассмотрим пару конкретных примеров: аутентификация и шифрование данных.
Аутентификация
Подробно останавливаться на минусах парольной аутентификации нет смысла. Слишком много сообщений о взломанных страничках и почтовых ящиках нам приходилось слышать. А с помощью криптографии на токенах реально реализовать «любой из тысячи» существующих протоколов аутентификации, для которого ни перехват с модификацией трафика, ни кража БД с сервера не дадут результата для нарушителя. Пользователь может забыть пароль, но не может забыть ключ, т.к. последний надежно хранится на токене. Аутентифицироваться с токеном также удобно, как и по паролю.
Шифрование данных
Обычно данные шифруются на криптографическом ключе, а сам ключ шифруется на пароле. Безопасность всей схемы целиком и полностью зависит от пароля, который опять же не всегда сложен и случаен, набирается на клавиатуре, может быть забыт и т.д. В случае с токеном, возможны два варианта решения:
1. Ключ хранится на токене и не покидает его. Такой способ подходит только для малых объемов информации, т.к. скорость дешифрования при помощи токена не достаточно велика. Нарушителю извлечь ключ нереально.
2. Ключ хранится на токене, но при шифровании попадает в оперативную память. Этот способ применяется, например, для де/шифрования тома целиком. Извлечь ключ возможно, но не совсем тривиально. Пароль же украсть гораздо проще.
Конечно, за решения с помощью токенов придется платить, но к счастью, рублями, а не нервами и временем. Несмотря на то, что токены содержат полный арсенал криптографических операций, достаточно сложных для понимания большинством пользователей, само применение токена не представляет особого труда и интуитивно понятно. Токен действительно не требует от пользователя специальных профильных знаний и глубокого понимания заложенных в него механизмов. И он потенциально способен прийти на смену паролей и всего, что с ними связано.
Уверен, что при распространенности решений на основе токенов удастся избежать различных неприятных случаев, связанных с кражей паролей, а также увеличить уровень безопасности в глобальном смысле.
Искренне надеюсь, что у читателей остались вопросы, ведь рассказал о токенах я крайне мало. С удовольствием отвечу на них в комментариях!
Обзор аутентификации на основе токенов
В прошлом для аутентификации в большинстве приложений и веб-сервисов пользователи должны были запоминать и при каждом логине вводить свои пароли. Кроме неудобства, это создавало ещё и угрозы безопасности, поскольку пользователи часто выбирали слабые пароли и использовали их в нескольких сервисах. Аутентификация на основе токенов устраняет подобные проблемы. Давайте разберёмся, как она реализуется.
Что такое аутентификация на основе токенов?
Аутентификация на основе токенов упрощает процесс аутентификации для уже известных пользователей. Для начала работы пользователь отправляет запрос к серверу, указав имя пользователя и пароль. Затем сервер подтверждает их на основании значений, зарегистрированных в его базе данных идентификационной информации. Если идентификационные данные подтверждены, сервер возвращает токен аутентификации (который тоже хранится в базе данных).
Когда тот же пользователь в дальнейшем шлёт запросы на доступ к защищённым ресурсам, эти запросы могут быть авторизованы при помощи токена аутентификации вместо имени пользователя и пароля. Сервер сверяет токен с зарегистрированным в базе данных токеном и предоставляет доступ. Аутентификацию можно реализовать на основе различных типов токенов, например, OAuth и JSON Web Tokens (JWT).
JWT использует безопасный способ, основанный на подписанных токенах, что позволяет с лёгкостью выявлять модификации. Аппаратные токены могут содержать идентификационные данные или генерировать одноразовый пароль.
Как работает аутентификация на основе токенов?
Существует множество способов предоставления пользователям токенов аутентификации — аппаратные токены, одноразовые пароли (обычно передаваемые через мобильный телефон) и программные токены, обычно основанные на стандарте JWT.
Все токены безопасным образом хранят идентификационную информацию и данные пользователя. Токен также может подтвердить, что данные верны и их не модифицировали — важное требование безопасности с учётом множества современных законов о конфиденциальности. Также они значительно повышают удобство работы для пользователя, поскольку позволяют пользователям выполнять вход без необходимости запоминания паролей.
Аутентификация на основе токенов обычно состоит из четырёх этапов:
Основные типы токенов аутентификации
Вот несколько популярных типов токенов, используемых разработчиками для аутентификации пользователей или аккаунтов сервисов.
Аппаратные токены (USB)
Аппаратные токены — это физические устройства, обеспечивающие авторизацию пользователей для доступа к защищённым сетям. Также иногда их называют токенами аутентификации или безопасности. Задача аппаратного токена — обеспечение дополнительного слоя защиты благодаря двухфакторной или многофакторной аутентификации (2FA или MFA). Владелец токена привязывает токен к системе или сервису, доступ к которому ему необходим.
Аппаратные токены спроектированы с учётом удобства для пользователей и возможности настройки, поэтому они могут иметь различные форматы. Самыми распространёнными типами токенов являются брелки, USB и беспроводные токены. Аппаратные токены можно разделить на три категории.
JSON Web Tokens (JWT)
JSON Web Token (JWT) — это открытый стандарт (RFC 7519). Он определяет простой автономный способ защищённой передачи информации между сторонами. Стандарт JWT использует объекты JavaScript Object Notation (JSON) для передачи токенов между сторонами. Эти токены могут использоваться для аутентификации, а также для передачи дополнительной информации о пользователе или аккаунте.
Благодаря своему малому размеру JWT могут передаваться как URL, параметры POST или заголовки HTTP и доставляться быстро. JWT содержит всю необходимую информацию о сущности, чтобы избежать многократных запросов к базе данных. Получателю JWT не нужно вызывать сервер, чтобы проверить токен.
JWT состоит из трёх частей:
Одноразовые токены One-Time Password (OTP)
Токены One-time password (OTP) — это защищённые аппаратные устройства или программы, способные генерировать одноразовые пароли. Чаще всего это personal identification numbers (PIN) — числовые коды длиной 4-12 цифр.
Для генерации или получения одноразовых паролей часто применяются смартфоны. После того, как пользователь доказал, что владеет конкретным телефоном, он может использовать приложение аутентификатора, генерирующее пароли OTP — в этом случае телефон служит генератором кодов. Или же OTP могут отправляться в устройство через SMS.
Одноразовые пароли усиливают существующие системы идентификации и паролей, добавляя в них динамически генерируемые идентификационные данные. Токены OTP генерируют PIN синхронно или асинхронно, это зависит от их поставщика:
API-токены
Если вкратце, то API-токены используются как уникальные идентификаторы приложения, запрашивающего доступ к сервису. Сервис генерирует API-токен для приложения, чтобы оно использовало его при запросе сервиса. Для аутентификации и предоставления доступа API-токен можно сопоставить с сохранённым токеном. В некоторых случаях можно реализовать Session ID, но это бывает очень нечасто.
API-токены получили популярность благодаря тому, что они заменяют небезопасную практику отправки сочетаний имени пользователя и пароля по HTTP. Одним из самых популярных сегодня способов реализации безопасности API является OAuth2 (токены доступа).
Безопасна ли аутентификация на основе токенов?
Киберпреступления становятся всё более изощрёнными, поэтому поставщики сервисов с удалённым управлением должны непрерывно обновлять методики и политики безопасности. В последнее время выросло количество атак, нацеленных на идентификационные данные при помощи таких способов, как фишинг, брутфорс и атаки по словарю. Это значит, что аутентификация больше не может использовать только пароли.
Аутентификация на основе токенов в сочетании с дополнительными техниками аутентификации может создать более сложный барьер, чтобы помешать умным хакерам использовать украденные пароли. Токены можно получать только с уникального устройства, которое их создало (например, смартфона или брелка), благодаря чему они становятся сегодня высокоэффективной методикой авторизации.
Хотя платформы токенов аутентификации совершили большой прогресс, угроза частично сохраняется. Хранящиеся в мобильных устройствах токены легко использовать, но они могут оказаться доступными из-за уязвимостей устройства. Если токены отправляются текстовым сообщением, их можно легко перехватить во время передачи. Если устройство украдено или утеряно, злоумышленник может получить доступ к хранящимся на нём токенам.
Однако всегда нужно помнить о том, что никогда не стоит полагаться на один способ аутентификации. Аутентификация токенами должна считаться только одним из компонентов стратегии двухфакторной или многофакторной аутентификации.
Плюсы и минусы программных токенов
Как и в случае с любой методологией или техникой, при выборе программных токенов нужно учитывать их достоинства и недостатки.
Как узнать токен ВК и как он выглядит?
Сегодня мы попробуем разобраться, можно ли узнать токен от ВК другого пользователя. Попутно, объясним, что это за штука такая и с чем ее едят.
Забегая вперед, сразу ответим, законных способов узнать токен чужого аккаунта ВК, нет. Разве что, вынудить человека вам его сообщить, открыто или хитростью.
Что такое токен?
Токен (access_token) – это ключ или код доступа. Еще, его называют подписью, зашифрованной информацией, секретным шифром.
Не путать с логином и/или паролем, это совершенно разные вещи.
Логин и пароль – это входные данные от страницы. Token – это комбинация, разрешающая или запрещающая определенный набор действий.
Для чего нужен этот ключ? Что он открывает, подписывает и какую информацию хранит?
Каждый раз, когда пользователь через вспомогательную утилиту совершает в ВК какое-то действие, сервер идентифицирует его. Это делается с целью определить круг полномочий этого приложения.
Например, пользователь авторизовывается в ВК через Kate Mobile. Если он входит на страницу, сервер понимает, хозяин это или гость. Для последнего отображается лишь часть информации, ограниченная настройками приватности. У хозяина доступ полный. То есть, и к скрытым фоткам, и к личным данным, и возможность выполнить любые настройки. Или, пользователь хочет опубликовать что-то на стене. Сервер уточняет, есть ли у данной проги доступ на это действие. Если да, позволяет сделать пост, если нет, выдает ошибку. И т.д.
Каким образом система производит идентификацию? Она считывает подпись пользователя. Тот самый токен. Представляет собой уникальную длиннющую строку из английских букв и цифр. Она содержит ФИО человека и перечень разрешенных функций.
Если кому-то удастся узнать чужой токен, он сможет заходить в ВК от имени его владельца. Соответственно, получить полный доступ к его возможностям и полномочиям.
Код может соответствовать, как пользователю, так и сообществу или приложению (например, игре какой-нибудь). Ключ доступа группы создается в ее настройках. Приложения – в настройках программы. Пользователя – складывается автоматически, когда человек авторизовывается в ВК.
Вот пример действия пользовательского токена:
Как узнать токен?
Давайте рассмотрим, как узнать и где найти токен своей страницы ВК и своего сообщества.
Код профиля
Вы должны понимать, токен есть не у каждой страницы. Он не является аналогом логина и пароля, поэтому, как правило, мало кому нужен. Если вы еще не генерировали ни одного ключа, инструкция ниже «споткнется» на «Error».
Итак, рассмотрим, как узнать или где взять токен ВК своей страницы (не чужой):
Это делается прямо из браузера:
Ключ доступа группы
Допустим, вы являетесь админом некоего сообщества. Ранее, вы подключили к нему сервис по созданию чат-ботов. Был сформирован ключ доступа, который сейчас вы хотите посмотреть.
Где взять и как узнать токен группы ВК?
Ключ приложения
Рассмотрим, как узнать токен пользователя по id созданного им приложения в ВК:
Чтобы включить приложение, вставьте в адресную строку браузера ссылку: https://oauth.vk.com/authorize?client_id=12345&scope=photos,audio,video,docs,notes,pages,status,offers,questions,wall,groups,email,notifications,stats,ads,offline,docs,pages,stats,notifications&response_type=token. Вместо 12345 впишите ID приложения.
После нажатия Enter выйдет окно с разрешениями, которые, в случае подтверждения, запишутся на токен.
Можно ли узнать чужой код доступа?
Итак, вас интересует, как узнать токен другого человека, например, друга в ВК. Мы уже писали вначале, это невозможно. По крайней мере, законным или официальным путем. Данные сведения считаются закрытыми и надежно охраняются системой безопасности соцсети.
Если умеете взламывать, вперед! Но вы должны понимать, что идете на правонарушение. Со всеми вытекающими. В сети можно найти уйму способов узнать токен ВК другого человека, как рабочих, так и нет. Мы против неправомерных действий, а потому, ничего тут рекомендовать не станем. Упомянули же об этом лишь для полноты картины.
Что дает знание ключа?
Мы рассказали, как узнать свой токен ВК со страницы, и пояснили, что чужие ключи недоступны. Теперь поговорим о том, что же они «открывают».
Вы получите доступ к всем разрешениям данного пользователя, сообщества или приложения.
Например, вы завладели кодами, которые были выданы приложению «Гости ВК». Ему был разрешен доступ к списку контактов, фотографиям, и, например, личным данным хозяина страницы. Значит и вы теперь сможете посмотреть его друзей, альбомы и закрытые личные данные. Все остальное станется под запретом: сообщения не напишете, настройки не поменяете, ленту новостей не почитаете.
И т.д. Чем больше полномочий давал полученный код, тем больше теперь у вас возможностей. Получается, страница остается при своем владельце, но человек, который завладел ее кодами, тоже может на ней похозяйничать. В рамках дозволенного, конечно. Например, посмотреть или включиться в чужую беседу ВК, если удалось узнать токен, получится только если у последнего есть такое разрешение.
К слову, ни один токен ни дает узнать пароль, поэтому отжать аккаунт злоумышленники никак не сумеют.
Теперь вы знаете, где в ВК найти токены. Удалить их невероятно просто: завершите все сеансы на странице или смените пароль. Удалить ключи в сообществе можно через Управление – Работа с API – Удалить.
На этом у нас все. Удалось переварить? Перечитайте еще раз!
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server: