Единая авторизация: что это такое и как работает — Журнал «Код»

Что такое сессии?

Попробую рассказать в паре абзацев.

Сессии – это механизм, который позволяет однозначно идентифицировать пользователя.
По-человечески это значит, что для каждого посетителя сайта можно создать уникальное “хранилище”, к которому будет доступ только у этого самого посетителя.
Хранилище это хранится в файле на сервере.

На самом деле сессии хранятся не обязательно в файлах. Например, cms Modx хранит их базе данных.
Но сейчас нам это не важно, главное, что сессии предоставляют удобный способ работать с данными, уникальными для пользователя.
Для нас сессия выглядит как обычный ассоциативный массив под названием $_SESSION, в разные поля которого можно записать хоть число, хоть строку, хоть сериализованный объект.

1 Словесное описание решаемой задачи

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

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

1 Время восстановления/энтропия входных параметров

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

Если у вашей системы есть на входе A,B,C,D,E,F — факты о пользователе, то если вы будете объединять все в одно, то получите A * B * C * D * E * F комбинаций, которые невозможно эффективно кешировать. По возможности следует найти такую комбинацию входных, что бы у вас было A * B * C и D * E * F комбинаций, а еще лучше A * B, C * D, E * F, которые вы уже легко сможете вычислять и кешировать.

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

2 Детализация авторизации

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

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

2 обобщенная модель данных

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

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

Детально опишем все имеющиеся определения с которыми будем дальше работать.

1 Пользователь

Субъект, чей доступ необходимо авторизовать.

Данное определение задает субъекты, которые могут быть как людьми, так и автоматическими системами, которые получают доступ к вашим ресурсам. У любого пользователя могут быть свои роли, разрешения и группы.

10 О кешировании данных

Основной проблемой при работе авторизации является точка в которой необходимо кешировать результаты, что бы работало быстрее все, да еще желательно так, что бы нагрузка на ЦПУ не была высокой. Вы можете поместить все ваши данные в память и спокойно их читать, но это дорогое решение и не все готовы будут себе его позволить, особенно если требуется всего лишь пара ТБ ОЗУ.

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

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

Даже если вам данные будут предоставлять за 0,1 мс, то ваш код будет работать все равно медленно. Очевидным решением будет кешировать сразу роли пользователя! В итоге у нас будет кеш Пользователь -> Роль[]. При таком подходе на какое-то время микросервис сможет обрабатывать запросы от пользователя без необходимости нагружать другие микросервисы.

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

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

2 Сервис

Множество ресурсов объединенных в единое целое, как пример сервис проектов.

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

3 Ресурс

Единичный объем информации для работы авторизации, например проект.

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

5 Роль

Множество разрешений, по сути под словом роль всегда подразумевается множество разрешений.

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

Ролевые модели позволяют как выполнять вертикальное, так и горизонтальное разграничение доступа (описание ниже). Из типа разграничения доступа следует, что сами роли делятся на типы:

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

Подробное описание использования типа ролей и формы авторизации ниже.

Роль имеет следующие связи:

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

6 Группа

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

Группы используются исключительно для горизонтального разграничения доступа (описание ниже). Даже если вы будете использовать группы для доступа к сервисам, то это все равно горизонтальное разграничение доступа, потому что сервис — это совокупность ресурсов.

Группа имеет следующие связи:

7 Вертикальное и горизонтальное разграничение доступа.

Самым простым способом представить себе работу авторизации — это нарисовать таблицы на каждого пользователя и каждый сервис, где колонки будут задавать разрешения, а строки — ресурсы, на пересечении ставятся галочки там, где доступ разрешен (привет excel-warrior’ам).

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

8 Глобальность/локальность авторизации доступа в микросервисах

Несмотря на то, что все роли могут хранится в единой БД, то вот связи между ними и пользователями хранить все вместе на всю вашу огромную систему — это типичный антипаттерн, делать так является грубейшей ошибкой, это все равно что POSIX права на файлы хранить в облачном сервисе, вместе с таблицей inode.

9 Конъюнктивная/дизъюнктивная форма авторизации

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

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

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

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

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

1 Закрытый онлайн аукцион

Организатор может создать аукцион, пригласить участников. Участник может принять приглашение, сделать ставку.

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

2 Логистика

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

Для реализации такого функционала нам потребуется реестр регионов и магазинов в качестве отдельного микросервиса, назовем его С1. Заявки и историю будем хранить на С2. Авторизация — А.Далее при обращении продавца для получения списка его магазинов (а у него может быть их несколько)

, С1 вернет только те, в которых у него есть меппинг (Пользователь, Магазин), так как ни в какие регионы он не добавлен и для продавца регионы всегда пустое множество. Разумеется при условии, что у пользователя есть разрешение просматривать список магазинов — посредством микросервиса А.

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

3 Секретные части документа

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

Когда пользователь обращается в сервис для получения блоков документа, микросервис в авторизации проверяет роль пользователя на чтение документов, далее в БД каждый блок имеет флаг — секрет. У документа есть меппинг (Пользователь, Документ) — список пользователей, которые подписали соглашение.

4 Команда и ее проекты

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

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

Допустим, что Вася — разработчик и ему нужно вызвать метод develop на микросервисе для выполнения своих обязанностей. Этот метод потребует у Васи роли в проекте — Разработчик.Как мы уже договаривались — регистрация пользователя в каждый проект для нас недопустима.

Поэтому микросервис проектов обратится в микросервис групп, что бы получить список групп, в которых Вася — Разработчик. Получив список этих групп можно легко проверить уже в БД микросервиса проектов — есть ли у проекта какая-нибудь из полученных групп и на основании этого предоставлять или запрещать ему доступ.

2 Архитектура решения

Для решения поставленной задачи нам необходимы следующие микросервисы:

1. Ролевая модель для глобальной авторизации запросов
2. Чайный сервис для предоставления возможности пить чай и получать статистику по выпитому
3. Кракен — гейт с проверкой доступа к точке, все остальные проверки совершит чайный сервис

Графически это будет выглядеть так:

В качестве БД будем использовать PostgreSQL.Предусмотрим следующие обязательные для решения задачи роли:

1. Сотрудник — для возможности пить чай;
2. Удаленный сотрудник — для доступа к микросервису кракена (так как сотрудники в офисе не должны иметь возможности пить чай через точки распрастранения чая);
3. Кракен — учетная запись микросервиса, что бы была возможность обращаться к API чайного сервиса;
4. Авторизационная учетная запись — для предоставления доступа микросервисов к ролевой модели.

5 реализация микросервисов

Для реализации воспользуемся Spring фреймворком, он довольно медленный, но зато на нем легко и быстро можно реализовывать приложения. Так как за перформансом мы не гонимся, то попробуем на нем достичь скромных 1к рпс авторизованных пустых запросов (хотя люди на спринге умудрялись 100к пустых запросов проворачивать [1]).

Весь проект поделен на несколько репозиториев:

Для начала разберемся с базой данных ролевой модели:

Oauth = fetch request token redirect to authorization fetch access token call api

В примере с GMail мы использовали 2 вида удаленных вызовов: а) редирект через браузер; б) обращение к API изнутри скрипта.

И мы вскрыли ряд проблем с безопасностью, что наводит на мысль: вызовов должно быть больше. Так и происходит в OAuth: добавляются еще промежуточные запросы от скрипта Consumer-а к Provider-у, оперирующие токенами. Давайте их рассмотрим.

Авторизация для приложений, имеющих серверную часть

1. Редирект на страницу авторизации
2. На странице авторизации у пользователя запрашивается подтверждение выдачи прав
3. В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
4. Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается access token

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

Авторизация полностью клиентских приложений

1. Открытие встроенного браузера со страницей авторизации
2. У пользователя запрашивается подтверждение выдачи прав
3. В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
4. Приложение перехватывает редирект и получает access token из адреса страницы

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

authorization codeaccess token

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

Авторизация с помощью подключенного устройства — это идентификация через Bluetooth (или нечто подобное), то есть присоединение одного устройства к другому, которое уже идентифицировало пользователя.

Например, для Mac OS X есть приложение KeyTouch, позволяющее авторизоваться на компьютере со сканом отпечатков пальцев со своего iPhone. Есть еще и Knock, который позволяет кликнуть по телефону, чтобы разблокировать компьютер.

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

Приложение Tether для iPhone

В домашнем офисе я использую приложение Mac OS X и iOS под названием Tether («связка»). После однократной синхронизации компьютера и телефона компьютер блокируется и разблокируется — в зависимости от близости телефона к компьютеру.

Tether сэкономил мне массу времени. Набор моего пароля с заглавными буквами, цифрами и символами может занять всего три или четыре секунды, но много раз повторять это каждый день, неделю и месяц — это уже слишком. Благодаря идентификации подключенного устройства к тому времени, когда я сажусь в кресло, мой компьютер уже разблокирован. Еще один пример — ключи от машины с Bluetooth.

Беспарольная авторизация

Беспарольная авторизация — это двухфакторная идентификация без первого шага. Нужно помнить свое имя пользователя, адрес электронной почты или номер телефона, после чего пользователь получает уникальный код для завершения входа. Он не создает пароль и не вводит его.

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

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

Авторизация в Slack

У Slack есть очень хороший пример беспарольной идентификации. На разных этапах входа в систему и процессов сброса пароля сервис использует «волшебную ссылку» (magic link) для идентификации пользователей. Уникальный URL отправляется на электронный адрес пользователя, и этот URL открывает приложение и позволяет ему войти.

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

Биометрическая идентификация

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

Наиболее распространенный пример — Touch ID компании Apple. Такие вещи действительно восхищают. Биология — наша истинная идентичность, она всегда с нами. Мы знаем об идее разблокирования телефонов или планшетов при помощи отпечатка пальца. Тем не менее биометрическая идентификация используется и в других местах (и с другими параметрами).

Windows Hello — это перспективная система идентификации для Windows 10, соединяющая камеры с датчиками (на компьютерах и устройствах) для распознавания лица, радужки глаз или отпечатков пальцев. Нужно просто открыть компьютер и заниматься своими делами, не жертвуя при этом безопасностью. Этот тип идентификации был до недавнего времени невозможен, особенно в масштабе Windows 10.

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

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

Биометрическая идентификация только начинает развиваться, но некоторые API и библиотеки позволяют нам пользоваться биометрической идентификацией уже сегодня. К ним относятся BioID Web Service, KeyLemon, Authentify и Windows Biometric Framework API (на котором, как мне кажется, построена Hello).

Восстановление предыдущей авторизации

Обычно,

access token

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

access token

‘а, во всех перечисленных выше вариантах, в дополнение к

access token

‘у может возвращаться еще

refresh token

. По нему можно получить

access token

Выбираем правильное хэширование

Идею хранения паролей нашли, то есть хранения не паролей, а их хэшей. А вот какой алгоритм хэширования выбрать?

Давайте посмотрим на то, что пробовали выше – простая функция md5. Алгоритма его расшифровки нет, но тем не менее md5 не рекомендуется для использования. Почему?

Помимо сложности самого алгоритма, есть и другой момент. Да, расшифровать пароль по хэшу нельзя, но его можно подобрать. Простым брутфорсом.
К тому же существуют многочисленные базы паролей md5, где всевозможные варианты хранятся тупо списком.
И подбор вашего пароля по известному хэшу займет столько времени, сколько понадобится для выполнения sql-запроса

    select password from passwords where hash='e10adc3949ba59abbe56e057f20f883e';

Конечно, вы сами не будете использовать пароль 123456, но как насчет ваших пользователей? Да, 123456 можно подобрать и руками, но в таком случае никакие алгоритмы не помогут.
Наша же задача максимально позаботиться о юзерах, которые выбирают пароли сложнее qwerty. Думаем дальше, гуглим.

Помимо md5 есть множество алгоритмов хэширования, sha256, sha512 и еще целая толпа. Их сложность выше, но это не отменяет опять-таки существования таблиц с готовыми паролями.
Нужно что-то хитрее.

Грабли вторые: «подслушивание» секретного ключа

Предположим, мы как-то защитили retpath, и он теперь может указывать только на наш сайт. Но проблема с параметром secret остается.

Secret можно подсмотреть из-за спины или перехватить методом прослушивания WiFi-трафика. Или на вашем сайте когда-нибудь найдется XSS-уязвимость, позволяющая «утянуть» секретный ключ. Имея значение secret, злоумышленник сможет прочитать вашу адресную книгу. Значит, нужно обезопасить secret от перехвата (в идеале — вообще его не передавать через URL).

Грабли первые: подмена адреса возврата retpath

Ну конечно же, вы догадались, что злоумышленник на своем сайте первым делом разместит ссылку

и заставит вас на нее кликнуть. В результате он получит секретный ключ, который вернул GMail, а значит, и ваши контакты:

Грабли четвертые: плохая идентификация consumer-а

GMail, конечно, хочет знать, кто пользуется его API. Разрешить доступ одним сайтам и запретить — другим… Значит, при формировании запроса в форме импорта контактов Consumer (сайт) должен «представляться» Service Provider-у (GMail-у). В нашем случае эту функцию частично выполняет retpath (имя сайта в нем), но данный способ не универсален, т.к. механизм «представления» должен быть задейстсован еще и при вызове API-методов.

Двухфакторная авторизация

Двухфакторная идентификация — это еще одно расширение традиционной идентификации при помощи пароля. После проверки комбинации имени пользователя и пароля уникальный код или URL пересылается по электронной почте либо отправляется SMS-сообщением владельцу аккаунта, который пытается войти в систему.

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

Авторизация в приложении Google

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

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

Google хорошо справляется с идентификацией. Компания используют правило «Доверять этому устройству 30 дней». Кроме того, она предлагает опцию двухфакторной аутентификации как один из вариантов и поощряет его применение, ни к чему не принуждая пользователей.

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

Для чего это нужно

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

Параллельно с этим в интернете есть сервисы, которыми пользуются все: Яндекс, Гугл, фейсбук или Вконтакте. Почему бы не брать данные о пользователе с этих сервисов?

Для этого и придумали OAuth.

Заглушка для авторизации

Функции, связанные с авторизацией, будут лежать в отдельном файле и своем пространстве имен. Создадим файл auth.php в api/v1/common – там, где уже лежит helpers.php.
Если вы разбирали уроки админки, особенно третий, про серверную часть, то эти пути вам будут знакомы. Если у вас свой проект, то кладите auth.php куда удобно.
Главное, потом правильно указать пути.

Содержимое auth.php

Имя пользователя и пароль

Буду честен: у меня возникают проблемы с традиционной моделью. В идеальном мире я бы устранил пароли вообще, но в реальности я пользуюсь этим методом в 99% своих проектов.

Почему? Такая проверка подлинности — наиболее понятный способ авторизации, и люди будут считать его самым надежным. Можно многое улучшить с точки зрения удобства и простоты использования. Создание и восстановление паролей можно упростить, а вход в систему ускорить и сделать менее запутанным.

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

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

Истоки проблемы

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

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

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

Для этого уже есть несколько методов и постоянно появляются новые. Традиционную аутентификацию при помощи пароля можно сделать комфортной и удобной. Вот актуальные способы:

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

Я буду оценивать каждый метод, исходя из нескольких факторов:

• частота использования: легкость настройки и обслуживания;
• безопасность: сложность идентификации для постороннего человека;
• комфорт: простота идентификации для пользователя аккаунта.

Как обойтись без шифрования. хэширование

Фокус в том, что не нужно хранить пароли в открытом виде, но и не нужно шифровать их с возможностью расшифровки. Пароли нужно хэшировать и в базе хранить не пароль, а его хэш.
Хитрым образом закодированную строку, которую нельзя расшифровать. Например, не password, а 5f4dcc3b5aa765d61d8327deb882cf99

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

Например, есть простая функция хэширования md5. Вот так она работает

Как работает единая авторизация

Для пользователя всё выглядит просто: нажал «Войти через Яндекс», подтвердил Яндексу своё желание войти на нужный сайт, и всё — вы уже зарегистрировались на новом сайте и можете им пользоваться. Но что происходит под капотом?

Когда посетитель, например, сайта о программировании, нажимает «Войти через Яндекс», этот сайт отправляет в Яндекс запрос и говорит: «Тут кто-то хочет войти на мой сайт через ваш сервис, можете разобраться?»:

Кодовая фраза

Секретные фразы безопаснее паролей, их легче запомнить. Об этом пишут уже больше десяти лет: от статьи «
Пароли-слова против паролей-фраз» в 2005 году до «Почему секретные фразы удобнее для пользователей, чем пароли» в 2022-м.

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

Хотите доказательств?
Zxcvbn — это проект Dropbox, определяющий надежность пароля. Другие сайты могут использовать Zxcvbn как определитель надежности пароля с открытым исходным кодом. В этой статье Dropbox есть статистика и сведения об истинной надежности различных паролей.

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

Впервые я использовал пароли-фразы с компанией интернет-банкинга
Simple, которая приветствует эксперименты и новые технологии, и они показали себя прекрасно. Мою фразу-пароль просто запомнить и легко набрать — особенно на мобильном телефоне.

Конкретизировать сообщение об ошибках ввода

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

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

Минусы oauth 2.0

Во всей этой красоте есть и ложка дегтя, куда без нее?

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

Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.

Напоминать пользователю о правилах

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

Авторизация на cайте BrowserStack

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

Об изобретении велосипедов

Хороший способ понять что-то — сделать это самому, наступив попутно на все разложенные грабли. Сейчас мы будем изобретать велосипед: попробуем представить, как бы мы решали задачу взаимодействия Consumer-а и Service Provider-а без всяких стандартизированных протоколов.

Во-первых, напишем саму форму импорта контактов с GMail:

Далее попросим разработчиков GMail сделать так, чтобы при переходе пользователя по URI /auth.php ему бы выдавалась форма авторизации (в нашем веломире GMail написан на PHP). После успешного ввода пароля пользователь должен редиректиться на сайт, чей URL указан в параметре retpath.

Итак, после ввода пароля пользователь будет возвращаться к нам на сайт по следующему адресу:

А мы из скрипта /import.php обратимся к API GMail, передадим в него ключ Y49xdN0Zo2B5v0RR и загрузим контакты:

Ну что же, давайте теперь считать грабли (потому что шишки считать будет уже поздно).

Ограничивать или исключать правила для паролей

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

Регистрация на сайте GoDaddy

В США и Великобритании 73% взрослых людей
используют на всех своих аккаунтах один и тот же пароль. Если ваши правила не дают пользователю использовать его стандартный пароль — он создает уникальный и, как правило, очень быстро его забывает. Исключив правила для паролей, вы даете пользователю возможность помнить пароль, чем повышаете юзабилити своего сервиса.

Зачем нам навязывают этот комплекс правил? Существуют исследования, которые утверждают, что длинные пароли эффективнее паролей с различными символами, но об этом я расскажу позже.

План этой статьи

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

1. Рассмотрим проблемы, которые возникают при «ручной» реализации кросс-авторизации.
2. Поговорим о том, что такое «приложение» и кто такой Consumer.
3. Коснемся основ криптографии.
4. Обозначим демо-приложение, которое мы будем писать в этой статье.
5. Определимся с тестовым сервером OAuth, на котором будем экспериментировать.
6. Пройдем по всем шагам протокола OAuth и приведем исходники скрипта.

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

Это довольно распространенная опция, в особенности для мобильных устройств, но стоит применять ее повсеместно (включая рабочие компьютеры).

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

Подсказки Люка Вроблевски

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

Приложение = consumer доступ к api

При работе с OAuth важно, что термин Consumer не ограничивается смыслом «сайт». Consumer — это некоторое

приложение

, а уж где оно размещено, не так важно. Примеры Consumer-ов из реальной жизни:

Но из одного OAuth каши не сваришь. Действительно, все, что дает OAuth, — это возможность авторизоваться на удаленном сервисе (Service Provider) и делать автризованные запросы к API. Не важно, как устроен этот API: это может быть чистый SOAP, REST-подход т. д. Главное, чтобы каждый метод API принимал на вход специальные параметры, передаваемые согласно протоколу OAuth.

Регистрация приложения и его параметры

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

После регистрации приложения вам выдается 5 параметров, которые требуются для работы с OAuth. Вот как они могут выглядеть:

Сообщение = документ цифровая подпись

«Цифровая подпись» — звучит страшно, но на самом деле это достаточно очевидная вещь. Когда вы ручкой подписываетесь на каком-либо документе, вы удостоверяете, что этот документ написан вами, а не кем-то другим. Ваша подпись как бы «добавляется» к документу и идет с ним в «одном комплекте».

Аналогично, цифровая подпись добавляется к некоторому блоку данных, удостоверяя: тот, кто сформировал эти данные, не выдает себя за другого. Цифровая подпись не шифрует документ, она лишь гарантирует его подлинность! Поставить подпись позволяет тот самый Shared Secret, который известен получателю и отправителю, но более никому.

Как это работает? Пусть наш $sharedSecret = 529AeGWg, и мы сообщили его шепотом на ухо принимающей стороне. Мы хотим передать сообщение «Мой телефон 1234567» с гарантированной защитой от фальсификации злоумышленником.

1. Consumer добавляет цифровую подпись к сообщению, в общем виде —

   $transfer = $message . "-" . md5($message . $sharedSecret);
   // $transfer = "Мой телефон 1234567" . "-" . md5("Мой телефон 1234567" . "529AeGWg")

2. Service Provider принимает данные, разбивает их обратно на 2 части — $message и $signature — и проделывает точно такую же операцию:

   $signatureToMatch = md5($message . $sharedSecret);
   // $signatureToMatch = md5("Мой телефон 1234567" . "529AeGWg");

   Дальше остается только сравнить получившееся значение $signatureToMatch с тем, что было в полученных данных $signature и рапортовать о подделке, если значения не совпали.

Социальный вход

Социальный вход или вход через авторитетный проверенный сайт — популярный и удобный способ идентификации. Он предназначен не только для входа в систему. У American Express есть Amex Express Checkout, откуда вы входите на свой Amex-аккаунт, чтобы безопасно оплачивать товары на сторонних сайтах. Вы идентифицированы, и уже не нужно отправлять данные кредитной карты продавцу.

Форма авторизации на простом html с пояснениями

<div class="form_auth_block">
  <div class="form_auth_block_content">
    <p class="form_auth_block_head_text">Авторизация</p>
    <form class="form_auth_style" action="#" method="post">
      <label>Введите Ваш имейл</label>
      <input type="email" name="auth_email" placeholder="Введите Ваш имейл" required >
      <label>Введите Ваш пароль</label>
      <input type="password" name="auth_pass" placeholder="Введите пароль" required >
      <button class="form_auth_button" type="submit" name="form_auth_submit">Войти</button>
    </form>
  </div>
</div>

.form_auth_block{
    width: 500px;
    height: 500px;
    margin: 0 auto;
    background: url(http://www.dailycompass.org/wp-content/uploads/2022/01/Bubbles.jpg);
    background-size: cover;
    border-radius: 4px;
}
.form_auth_block_content{
  padding-top: 15%;
}
.form_auth_block_head_text{
    display: block;
    text-align: center;
    padding: 10px;
    font-size: 20px;
    font-weight: 600;
    background: #ffffff;
    opacity: 0.7;
}
.form_auth_block label{
    display: block;
    text-align: center;
    padding: 10px;
    background: #ffffff;
    opacity: 0.7;
    font-weight: 600;
    margin-bottom: 10px;
    margin-top: 10px;
}
.form_auth_block input{
  display: block;
  margin: 0 auto;
  width: 80%;
  height: 45px;
  border-radius: 10px;  
  border:none;
  outline: none;
}
input:focus {
  color: #000000;
  border-radius: 10px;
  border: 2px solid #436fea;
}
.form_auth_button{
    display: block;
    width: 80%;
    margin: 0 auto;
    margin-top: 10px;
    border-radius: 10px;
    height: 35px;
    border: none;
    cursor: pointer;
}
::-webkit-input-placeholder {color:#3f3f44; padding-left: 10px;} // Это стили для placeholder
::-moz-placeholder          {color:#3f3f44; padding-left: 10px;} // Это стили для placeholder
:-moz-placeholder           {color:#3f3f44; padding-left: 10px;} // Это стили для placeholder
:-ms-input-placeholder      {color:#3f3f44; padding-left: 10px;} // Это стили для placeholder

Фундамент oauth

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

Шаг 8

И последний штрих. Мы можем ограничивать доступ не только к странице админки, но и к любой другой. Для этого достаточно открыть сессию и проверить наличие метки в ней. Чтобы не копировать на каждую новую страницу эти блоки кода — мы их можем вынести в отдельный файл (auth.php) и затем просто подключать этот файл на страницах, к которым нужно ограничить доступ по паролю. Содержимое файла auth.php будет таким:

Заключение

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

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

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

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

11 Выводы по обобщенной модели

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