что делать после авторизации
Нужна ли авторизация после регистрации?
Занимаясь проектированием одного сервиса, я задумался: имеет ли смысл авторизовать пользователя сразу после регистрации или лучше не делать этого? С одной стороны, опыт подавляющего большинства сайтов говорит нам о том, что посетители привыкли к тому, что после процедуры регистрации им больше ничто не мешает пользоваться услугами сайта. С другой, многие используют всевозможные приложения и менеджеры паролей (интегрированные в браузер или сторонние сервисы), а значит, при следующем входе им придется вспоминать свои логин-пароль вместо того, чтобы войти почти автоматически.
Вместо того, чтобы выбирать, какой же из вариантов удобнее, имеет смысл воспользоваться преимуществами обоих способов и свести схему регистрации пользователя к такой, что после отправки данных, введенных в регистрационную форму, пользователь попадает на страницу авторизации, где в соответствующие поля уже введена вся необходимая информация (не забываем при этом в базу писать не сам пароль, а, к примеру, его соленый хэш). Нажав кнопку «Войти», пользователь может сохранить свои логин-пароль в менеджере паролей, а процедура регистрации усложняется всего на один шаг. Даже вариант с автоматической генерацией пароля и отправкой его на почту требует больше действий.
Если кто-то захочет попробовать, я сделал простой пример системы, который показывает общее развитие сценария.
Фактически, с точки зрения безопасности подобный подход не слабее обычного варианта входа, но позволяет пользователям воспользоваться удобным и привычным для многих инструментом запоминания паролей. Еще одним преимуществом такой модификации является то, что в анкете на регистрацию можно убрать поля ввода пароля, оставив там в лучшем случае всего лишь поле для почты.
Надёжная авторизация для веб-сервиса за один вечер
Предыстория
Осень 2015-ого. Примерно полтора года назад, когда мне случилось стать участником разработки проекта, где пользователей существенно больше пары десятков человек, я наконец-то впервые в своей жизни задумался о надёжности авторизации.
По сути, авторизация — это то, с чего начинается процесс взаимодействия зарегистрированного пользователя с системой (для незарегистрированного пользователя всё начинается с регистрации, и эти два процесса, как вы уже догадались, очень сильно взаимосвязаны). Я внезапно осознал, что во всех проектах, что я делал до этого, с безопасностью всё очень плохо.
Достаточно рассмотреть простейший пример: кто-то подобрал пароль, или человек каким-то образом скомпрометировал его. Конечно, у нас в базе данных хранятся хэши с использованием соли, мы даже настолько продвинуты, что используем только HTTPS… Но это никак не спасёт нас от человеческого фактора.
Что делает в случае взлома грамотная система? Блокирует аккаунт (совсем хорошо — если автоматически, по ряду необычных признаков в поведении пользователя), в дальнейшем предлагая средства для восстановления: привязанный телефонный номер, контрольный вопрос, и т.д. Привязка сотового — отличная мера с крайне высокой надёжностью. К сожалению, у нашего проекта не было на это средств, поэтому приходилось обходиться без этого. Благо, блокировку можно реализовать, посадив человека на специальный почтовый ящик, или даже принимать экстренные звонки на сотовый.
И тут традиционный метод, который применяют многие начинающие разработчики (найденный в книгах, либо в статьях в интернете) даёт осечку. Дело в том, что этот метод предполагает хранение авторизации в сессиях. Это статья не относится к конкретному языку, и справедлива для любой платформы, но я буду иллюстрировать всё на примере PHP.
Стандартная реализация
Итак, сессия в PHP по умолчанию хранится в файле. Её id сохраняется в cookie (если куки отключены — задействуется механизм передачи через адресную строку, если это не отключено в конфигурации). Время жизни такой сессионной куки по умолчанию — до момента закрытия браузера (и обычно его никто не меняет). Поэтому более продвинутые программисты реализуют галочку «запомнить меня», либо реализуют её функционал по умолчанию, без возможности отключить. Что они делают? Просто сохраняют в собственной куке айди пользователя. Но поскольку просто айди хранить как-то уж слишком стрёмно (любой может поставить любое число и получить доступ к произвольному аккаунту), то часто вместе с айди за компанию сохраняют и пароль. В открытом виде.
Если кто-то не понимает, чем это плохо — представьте себе, что у нас пользователь пользуется очень старым, либо очень плохо реализованным браузером. Мы ведь не можем гарантировать, что браузер надёжно шифрует куки? Да и вирусы всякие могут быть у пользователя на компьютере, и в случае особо серьёзной малвари может не спасти и шифровка — зловред может попытаться считать значения прямо из памяти, когда они расшифрованы. Человек, случайно оказавшийся у вашего компьютера в ваше отсутствие — сможет просто скопировать себе все интересующие куки, и в новых браузерах этот процесс стал ещё проще. Дыры в безопасности браузера могут потенциально привести к тому, что ваша кука станет доступна стороннему сайту (да, сейчас это крайней маловероятно, но чем чёрт не шутит).
Ну и самое главное — если у нас SSL используется только при авторизации (а на остальных страницах его решили отключить ради выигрыша в скорости, либо чтобы лучше работало промежуточное кэширование)… То наш пароль всё время передаётся открытым текстом. При каждом запросе. А пароль меняют редко, то есть это некий токен, который имеет долгий срок жизни. А теперь представим себе, что наш трафик кто-то перехватил…
Как быть?
Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.
Первое, что приходит на ум — хранить вместо пароля хэш от него. Это не особо поможет, если кто-то перехватит трафик, и не поможет при краже кук. Но вот в ситуации «кто-то открыл настройки и прошёлся по кукам, пытаясь запомнить значения» — сильно усложнит жизнь злоумышленнику.
Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).
Но если пароль всё же утёк — мы по-прежнему бессильны. Даже сменив пароль через форму восстановления либо изнутри системы — взломщик останется залогинен, пока не закроет браузер. Ведь в основе авторизации у нас всё ещё лежит сессия.
Можно, конечно, на PHP получить id сессии при логине, записать его куда-то в базу, а при сбросе пароля стартовать по очереди все сессии с айдишниками из базы и делать session_destroy()… Возможный вариант, но не обязательно следовать ему.
Итак, мы сформулировали основной список требований к нашей системе:
1. Быть простой в реализации
2. Желательно не зависеть от используемой серверной платформы
3. Позволить «выкинуть» взломщика из системы, завершив все открытые сессии, либо некоторые из них (на основе браузера/операционной системы/времени логина)
4. Видеть список всех своих открытых сессий в системе, просматривать его
5. Максимально затруднить атаку в случае отсутствия SSL (например, открытый Wi-Fi)
6. Не создавать неудобств легитимным пользователям
Приступаем к работе
Перво-наперво создадим в нашей базе данных (будем считать, что мы используем реляционную СУБД) таблицу для хранения сессий. Наших сессий (не путать с PHP-шными!). Таблица будет иметь следующие поля: id, user_id, ip, user_agent, time. В качестве времени будем хранить время создания сессии. Можно хранить и время последнего доступа, но вскоре мы увидим, что это избыточно, и можно к этому прибегнуть лишь в рамках денормализации, чтобы ускорить выборку данных. Создаваться сессия будет в момент авторизации, а также при регистрации (мы хотим, чтобы после регистрации пользователю не приходилось заполнять форму логина, и тут же авторизуем его). Также создадим вторую таблицу — log, с таким же набором полей. Туда будем добавлять запись при каждой авторизации (через форму входа или по кукам).
Теперь мы можем хранить на клиенте id сессии, и сверять его с базой. При этом сервер может проверить, что у нас совпадает юзер-агент и IP. Если хотя бы что-то одно не сходится — считаем, что пользователь не авторизован, и направляем его на страницу логина.
Но этого как-то мало — IP клиента взломщик может знать (и если он перехватывает трафик, то уж точно его знает), то же самое касается юзер-агента (который вообще получить не составляет никаких проблем). Нам хотелось бы хранить в cookie не пароль, а некую производную от пароля, привязанную к сессии… то есть к юзер-агенту и IP. Соответственно, если что-то стало отличаться — доступ прекратится. Поэтому, как вы уже догадались, разумно использовать хэш от этих переменных, и сохранять в куке его. При этом просто посмотрев на хэш, взломщик не только не сможет узнать пароль, но даже точно определить, какие именно компоненты были использованы при его создании (и с какими модификациями).
Создадим в таблице сессий ещё одну колонку — hash. Будем использовать её для хранения хэшей наших сессий.
Вопрос удобства
Но тут мы сталкиваемся с другой проблемой. Клиент может переключаться между разными IP (как минимум между домашним Wi-Fi и 3G в дороге, а ещё рабочим защищённым Wi-Fi, как пример). И было бы очень негуманно заставлять его вводить заново логин и пароль каждый раз при смене IP адреса. Как быть, хранить в куке целый список хэшей? При запросе на сервер отсылать его? Можно, но это несколько усложняет реализацию. Кроме того, это раздувает размер куки (при том, что нам основную часть времени может требоваться всего один хэш, мы будем хранить все когда-либо использовавшиеся), а при очистке кук мы (как пользователь) потеряем их все, и опять придётся с каждого IP адреса вводить пароль вручную.
Что, если привязать хэш только к юзер-агенту? Можно, но это существенно снизит безопасность. Нам нужен компромиссный подход.
Делегирование полномочий
Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!
Разобьём начальную стадию нашего внешнего скрипта (это тоже можно вынести в отдельный файл, но в данный момент это не важно) на два этапа. На первом мы смотрим, установлена ли обычная сессия PHP. Если нет — сразу перебрасываем пользователя на форму авторизации. Но форма при загрузке проверяет наличие кук, и если кука с хэшем нашей сессии существует, и хэш совпадает с ожидаемым (хэш-функция от пароля* и юзер-агента), то ставим переменные сессии (в первую очередь user_id), делаем запись в таблицу log, и обратно перебрасываем пользователя туда, откуда он пришёл (адрес раздела для возврата разумно передавать прямо в ссылке). Итак, если нет PHP-сессии, но есть куки, и куки соответствуют браузеру — пользователь залогинен.
Теперь рассмотрим вариант, когда сессия есть (после того, как пользователь залогинен по паролю из формы или по кукам, он тоже попадёт на этот шаг). И вот тут вступает в игру наш скрипт security.php. Вот его код:
Если нам нужна система банов — можно раскомментировать последние две строки. И не забываем, что чтобы не произошло бесконечного зацикливания, в скрипт авторизации проверку на бан тоже надо включить!
Скрипт прост как дважды два. Мы проверяем наличие сессии с нашими текущими параметрами и нашим текущим хэшем. Если что-то не совпало — нас попросят пройти повторную авторизацию через редирект. И вот тут происходит самое вкусное. Если у нас поменялся только IP — мы пройдём проверку, для нас создастся новая сессия, если её нет для этого IP (этот момент надо включить в код авторизации), и создастся новая кука.
Если у нас поменялся браузер (угнанная кука) — придётся вводить пароль, которого у взломщика нет, иначе зачем ему воровать куки. При этом IP скорее всего будет другим, но может быть и тем же (взломщик находится с нами в одной локальной сети). В случае, когда взломщик в одной сети с жертвой, и имеет тот же юзер-агент — к сожалению, мы никак не сможем отличить его от настоящего пользователя. Привет, беспарольный Wi-Fi.
Если поменялся только хэш (поменяли куку вручную? побились файлы на жёстком диске?) — придётся авторизоваться заново, ничего не поделать.
Наконец, можно очень эффектно моментально отключить доступ к аккаунту. Для этого даже не обязательно удалять строку с сессией. Достаточно удалить/поменять/добавить один символ в хэше (последнее поле). Пример из жизни — если легитимный пользователь по счастливому стечению обстоятельств первым успеет воспользоваться кнопкой смены пароля в кабинете — взломщика выкинет, причём при первой же перезагрузке страницы. У настоящего пользователя уже будет новая кука (в хэше будет использован новый пароль), старые сессии будут полностью удалены из таблицы, а новая сессия создана с новым хэшем. А взломщик останется со старым невалидным хэшем, который не пройдёт проверку в security.php. При первом же непрохождении будет сброшена сессия PHP, и выполнен редирект на авторизацию. Которую, опять же, нельзя пройти, имея неактуальный хэш от старого пароля.
Всё хорошо?
Почти. Данная система по-прежнему не защищает от кражи хэша из кук при открытом канале и отсутствии SSL. Кроме того, сложно обеспечить своевременную блокировку, если доступ к аккаунту утерян (особенно если взломщик уже сменил пароль). В этом случае очень помог бы сброс пароля через смс-команду с привязанного телефона — но для этого уже нужна возможность принимать и отправлять смс. А если она есть — то можно сразу внедрить двухфакторную авторизацию, которая снимет массу проблем. Но не проблему с необходимостью в SSL — поскольку всё равно результатом любой авторизации является получение некого токена доступа, работающего ограниченное время. И этого времени может быть достаточно, чтобы сделать от нашего имени что-то, что нам не понравится.
Данный код можно, наверное, сделать ещё лучше и надёжнее. Если у вас есть по этому поводу соображения — пишите их в комментарии. Пока что система зарекомендовала себя с очень хорошей стороны, и была использована уже минимум в трёх проектах, два из которых имеют массовый доступ.
Авторизация и аутентификация для всех
Аутентификация и авторизация необходимы для многих приложений. Допустим, вы разработали приложение и внедрили в него аутентификацию и авторизацию — использовали для этого стороннюю библиотеку аутентификации или платформу идентификации. Выполнив свою работу, как обычно вы не стали разбираться, что происходит за кулисами, или почему что-то происходит определенным образом. Но если вы хотите получить общее представление о том, что происходит на самом при использовании стандартов OAuth 2.0 и OpenID Connect, читайте дальше!
Аутентификация — это сложно. Почему так? Стандарты Auth хорошо определены, но в них сложно разобраться. И это нормально! Мы собираемся пройти через это максимально доступным способом. Мы рассмотрим концепции идентификации шаг за шагом, опираясь на наши знания по мере продвижения вперед. К тому времени, когда мы закончим, вы должны иметь фундамент и знать, куда нужно обратиться если вам нужно будет больше информации.
Введение
Когда я говорил семье или друзьям, что я «работаю в identity», они часто предполагали, что это означает, что я работал в правительстве, в организации выдающей водительские права, или что я помогал людям разрешать мошенничество с кредитными картами.
Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)
Цифровая идентификация
Цифровая идентификация это набор атрибутов, которые определяют отдельного пользователя в контексте функции, предоставляемой конкретным приложением.
Скажем, вы управляете компанией по продаже обуви онлайн. Цифровой идентификацией пользователей вашего приложения может быть номер их кредитной карты, адрес доставки и история покупок. Их цифровая идентификация зависит от вашего приложения.
Это приводит нас к …
Аутентификация
В широком смысле, аутентификация относится к процессу проверки того, что пользователь является тем, кем он себя заявляет.
Как только система сможет установить это, мы приходим к …
Авторизация
Авторизация касается предоставления или отказа в правах доступа к ресурсам.
Стандарты
Вы можете вспомнить, что я упомянул, что аутентификация основывается на четко определенных стандартах. Но откуда эти стандарты берутся?
Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).
IETF (Internet Engineering Task Force)
IETF — это большое открытое международное сообщество сетевых инженеров, операторов, поставщиков и исследователей, которые занимаются развитием интернет-архитектуры и бесперебойной работой интернета.
OIDF (OpenID Foundation)
OIDF — это некоммерческая международная организация людей и компаний, которые стремятся обеспечить, продвигать и защищать технологии OpenID.
Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:
OAuth 2.0
OAuth 2.0 является одной из наиболее часто упоминаемых спецификаций, когда речь идет о сети, а также часто неправильно представленной или неправильно понятой.
OAuth не является спецификацией аутентификации. OAuth имеет дело с делегированной авторизацией. Помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления или отказа в доступе к ресурсам. OAuth 2.0 предоставляет доступ к приложениям от имени пользователей.
Как было до OAuth
Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:
Допустим, вы использовали приложение под названием HireMe123. HireMe123 хочет настроить событие календаря (например, встречу на собеседование) от вашего имени (пользователя). HireMe123 не имеет собственного календаря; поэтому нужно использовать другой сервис под названием MyCalApp для добавления событий.
После того, как вы вошли в HireMe123, HireMe123 запросит у вас ваши учетные данные для входа в MyCalApp. Вы должны ввести свое имя пользователя и пароль на сайте HireMe123.
Затем HireMe123 используя ваш логин получить доступ к API MyCalApp, и затем сможет создавать события календаря с использованием ваших учетных данных.
Совместное использование учетных данных — это плохо!
Этот подход основывался на совместном использовании личных учетных данных пользователя из одного приложения с совершенно другим приложением, и это не очень хорошо.
Так как, HireMe123 поставил на карту защиты вашей учетной записи MyCalApp гораздо меньше. Если HireMe123 не защитит ваши учетные данные MyCalApp надлежащим образом, и они в конечном итоге будут украдены или взломаны, кто-то сможет написать несколько неприятных статей в блоге, но HireMe123 как бы останется в стороне.
HireMe123 также получает слишком большой доступ к MyCalApp от вашего имени. HireMe123 получает все те же привелегии, что и вы, потому что он использовал ваши учетные данные для получения этого доступа. Это означает, что HireMe123 может читать все ваши события календаря, редактировать их, изменять настройки и т. д.
Появление OAuth
Все эти недостатки приводит нас к OAuth.
OAuth 2.0 — это открытый стандарт для выполнения делегированной авторизации. Это спецификация, которая говорит нам, как предоставить сторонним пользователям доступ к API без предоставления учетных данных.
Используя OAuth, пользователь теперь может делегировать HireMe123 для вызова MyCalApp от имени пользователя. MyCalApp может ограничить доступ к своему API при вызове сторонними клиентами без риска совместного использования информации для входа или предоставления слишком большого доступа. Это делается с помощью:
Сервер авторизации
Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?
Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:
MyCalApp теперь имеет сервер авторизации. Предположим, что HireMe123 уже зарегистрирован как известный клиент в MyCalApp, что означает, что сервер авторизации MyCalApp распознает HireMe123 как объект, который может запрашивать доступ к своему API.
Предположим также, что вы уже вошли в систему с HireMe123 через любую аутентификацию, которую HireMe123 настроил для себя. HireMe123 теперь хочет создавать события от вашего имени.
HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.
Затем сервер авторизации MyCalApp запросит у вас согласие разрешить HireMe123 получать доступ к API MyCalApp от вашего имени. В браузере откроется приглашение, в котором будет запрошено ваше согласие на добавление в календарь событий HireMe123 (но не более того).
Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.
MyCalApp затем выдаст токен доступа для HireMe123. HireMe123 может использовать этот токен доступа для вызова MyCalApp API в рамках разрешенных вами разрешений и создания событий для вас с помощью MyCalApp API.
Ничего плохо больше не происходит! Пароль пользователя знает только MyCalApp. HireMe123 не запрашивает учетные данные пользователя. Проблемы с совместным использованием учетных данных и слишком большим доступом больше не являются проблемой.
А как насчет аутентификации?
На данный момент, я надеюсь, стало ясно, что OAuth предназначен для делегированного доступа. Это не распространяется на аутентификацию. В любой момент, когда аутентификация включалась в процессы, которые мы рассмотрели выше, вход в систему осуществлялся любым процессом входа в систему, который HireMe123 или MyCalApp реализовали по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он только покрывал авторизацию доступа сторонних API.
Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?
Проблема входа в систему
То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.
Но, как мы упоминали выше, OAuth 2.0 предназначен только для делегированного доступа. Это не протокол аутентификации. Но это не помешало людям попытаться использовать его и для аутентификации, и это представляет проблему.
Проблемы с использованием токенов доступа для аутентификации
Если HireMe123 предполагает успешный вызов API MyCalApp с токеном доступа, достаточным что бы пользователь считался аутентифицированным, у нас возникают проблемы, поскольку у нас нет способа проверить, был ли выдан токен доступа правильному пользователю.
Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.
Как уже упоминалось, это не остановило людей от неправильного использования токенов доступа и OAuth 2.0 для аутентификации. Быстро стало очевидно, что формализация аутентификации поверх OAuth 2.0 была необходима, чтобы разрешить входы в приложения сторонних разработчиков, сохраняя безопасность приложений и их пользователей.
OpenID Connect
Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.
OIDC — это уровень идентификации для аутентификации пользователей на сервере авторизации. Помните, что сервер авторизации выдает токены. Токены представляют собой закодированные фрагменты данных для передачи информации между сторонами (такими как сервер авторизации, приложение или API ресурса). В случае OIDC и аутентификации сервер авторизации выдает токены ID.
ID Токены
Идентификационные токены предоставляют информацию о событии аутентификации и идентифицируют пользователя. Идентификационные токены предназначены для клиента. Это фиксированный формат, который клиент может анализировать и проверять, чтобы извлечь идентификационную информацию из токена и тем самым аутентифицировать пользователя.
OIDC объявляет фиксированный формат для токенов ID, которым является JWT.
JSON Web Token (JWT)
JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.
Сегмент заголовка
Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:
Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).
Декодированный заголовок выглядит примерно так:
Сегмент полезной нагрузки
Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:
Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:
Оно также кодируется в base64Url.
Крипто сегмент
Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.
Когда клиент получает идентификационный токен, он также проверяет подпись с помощью ключа. (Если использовался алгоритм асимметричной подписи, для подписи и проверки используются разные ключи; в этом случае только сервер авторизации может подписывать токены.)
Claim
Claim можно перевести как требование, утверждение или как заявление.
Теперь, когда мы знаем об анатомии JWT, давайте поговорим подробнее об claim, этом фрагменте данных из сегмента полезной нагрузки. Согласно его названию, токены ID предоставляют идентификационную информацию, которая присутствует в формуле claim.
Аутентификационный Claim
Некоторые строки аутентификации в токене ID включают:
Одноразовый номер nonce привязывает запрос авторизации клиента к полученному токену. Одноразовый номер — это криптографически случайная строка, которую клиент создает и отправляет с запросом авторизации. Затем сервер авторизации помещает одноразовый номер в токен, который отправляется обратно в приложение. Приложение проверяет, совпадает ли одноразовый номер в токене с отправленным с запросом авторизации. Таким образом, приложение может проверить, что токен пришел из того места, откуда он запросил токен.
Идентификационные данные (Identity Claim)
Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:
Некоторые из стандартных строк профиля в токене ID включают:
После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.
Аутентификация с помощью ID токенов
Давайте посмотрим на OIDC аутентификацию на практике.
Обратите внимание, что это упрощенная схема. Есть несколько разных потоков в зависимости от архитектуры вашего приложения.
Наши объекты здесь: браузер, приложение, запущенное в браузере, и сервер авторизации. Когда пользователь хочет войти в систему, приложение отправляет запрос авторизации на сервер авторизации. Учетные данные пользователя проверяются сервером авторизации, и если все хорошо, сервер авторизации выдает идентификационный токен приложению.
Затем клиентское приложение декодирует маркер идентификатора (который является JWT) и проверяет его. Это включает в себя проверку подписи, и мы также должны проверить данные claim. Вот некоторые примеры проверок:
После того как мы установили подлинность токена ID, пользователь проходит аутентификацию. Теперь у нас есть доступ к identity claims и мы знаем, кто этот пользователь.
Теперь пользователь аутентифицирован. Пришло время взаимодействовать с API.
Доступ к API с помощью токенов доступа
Мы немного поговорили о токенах доступа ранее, еще когда мы смотрели, как делегированный доступ работает с OAuth 2.0 и серверами авторизации. Давайте посмотрим на некоторые детали того, как это работает, возвращаясь к нашему сценарию с HireMe123 и MyCalApp.
Токены доступа
Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.
В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.
В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.
Токены доступа прозрачны для клиента
Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?
Токены доступа могут измениться в любое время. У них должно быть короткое время истечения, поэтому пользователь может часто получать новые. Они также могут быть переизданы для доступа к различным API или использования разных разрешений. Клиентское приложение никогда не должно содержать код, который опирается на содержимое токена доступа. Код, который делает это, был бы хрупким и почти гарантированно сломался.
Доступ к ресурсным API
Допустим, мы хотим использовать токен доступа для вызова API из одностраничного приложения. Как это выглядит?
Мы рассмотрели аутентификацию выше, поэтому давайте предположим, что пользователь вошел в наше приложение JS в браузере. Приложение отправляет запрос авторизации на сервер авторизации, запрашивая токен доступа для вызова API.
Затем, когда наше приложение хочет взаимодействовать с API, мы присоединяем токен доступа к заголовку запроса, например, так:
Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.
Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?
Делегирование со Scopes
Как API узнает, какой уровень доступа он должен предоставить приложению, запрашивающему использование его API? Мы делаем это с помощью scopes.
Scopes (Области действия) «ограничивают возможности приложения от имени пользователя». Они не могут предоставлять привилегии, которых у пользователя еще нет. Например, если у пользователя MyCalApp нет разрешения на создание новых корпоративных учетных записей MyCalApp, scopes, предоставленные HireMe123, также никогда не позволят пользователю создавать новые корпоративные учетные записи.
Scopes делегируют управление доступом к API или ресурсу. Затем API отвечает за объединение входящих scopes с фактическими правами пользователя для принятия соответствующих решений по управлению доступом.
Давайте рассмотрим это на нашем примере.
Я использую приложение HireMe123, и HireMe123 хочет получить доступ к стороннему API MyCalApp для создания событий от моего имени. HireMe123 уже запросил токен доступа для MyCalApp с сервера авторизации MyCalApp. Этот токен содержит некоторую важную информацию, такую как:
HireMe123 отправляет запрос в API MyCalApp с токеном доступа в своем заголовке авторизации. Когда MyCalApp API получает этот запрос, он может увидеть, что токен содержит scope write: events.
Но MyCalApp размещает учетные записи календаря для сотен тысяч пользователей. В дополнение к рассмотрению scope в токене, промежуточному программному обеспечению (middleware) API MyCalApp необходимо проверить sub идентификатор пользователя, чтобы убедиться, что этот запрос от HireMe123 может только использовать мои привилегии для создания событий с моей учетной записью MyCalApp.
В контексте делегированной авторизации scopes (области действия) показывают, что приложение может делать от имени пользователя. Они являются подмножеством общих возможностей пользователя.
Предоставление согласия
Помните, когда сервер авторизации спрашивал пользователя HireMe123 о его согласии разрешить HireMe123 использовать привилегии пользователя для доступа к MyCalApp?
Этот диалог согласия может выглядеть примерно так:
HireMe123 может запросить множество различных областей, например:
В общем, мы должны избегать увеличения количества областей с правами пользователя. Тем не менее, можно добавить разные области для отдельных пользователей, если ваш сервер авторизации обеспечивает управление доступом на основе ролей (Role-Based Access Control — RBAC).
С RBAC вы можете настроить роли пользователей с определенными разрешениями на вашем сервере авторизации. Затем, когда сервер авторизации выдает токены доступа, он может включать роли определенных пользователей в свои области.
Ресурсы и что дальше?
Мы рассмотрели много материала, и даже не приблизились к рассмотрению всему что есть в области аутентификации и авторизации. Я надеюсь, что это была полезная статья по идентификации, авторизации и аутентификации.
В настоящее время я работаю над несколькими дополнительными постами в блоге, в которых более подробно рассматриваются веб-токены JSON, а также аутентификация и авторизация для приложений JavaScript.
Если вы хотите узнать больше, гораздо больше по этим темам, вот несколько полезных ресурсов для вас:
Выучить больше
Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.
Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..
JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.
OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.
Спасибо!
Если вы хотите пообщаться, я доступен в Твиттере на @KimMaida, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!