Все об AuthType или авторизация в Apache | Apache

Что такое оauth2.0?

Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0. 

Стандарт был принят в 2022 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем. 

OAuth 2.0 — это фреймворк авторизации.

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

Особенности:

Разберёмся подробнее в особенностях.

Что такое grant?

Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.

Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».

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

Существует 4 1 способа получения grant — grant type:

Authorization code

Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов. 

Oauth для полностью клиентских приложений

Стороннее приложение может представлять собой лишь графический интерфейс без серверной бизнес-логики и выполнять взаимодействие с сервисом API с помощью кода на клиенте — например, мобильное приложение календаря, заметок и т.д.

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

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

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

Oauth для приложений с серверной частью: рассмотрим по шагам

Последовательность шагов приведена на схеме ниже.

1. Пользователь перенаправляется на страницу авторизации, где у него запрашиваются разрешения для приложения на работу с данными его аккаунта.
2. После предоставления необходимых разрешений пользователь попадает на callback URL — адрес, указанный при регистрации приложения, предназначенный для завершения авторизации. При этом происходит подстановка кода авторизации в  GET-параметры адреса.
3. Сервер клиентского приложения формирует POST-запрос к серверу авторизации API с кодом авторизации в качестве параметра.
4. Сервер авторизации проверяет код и возвращает приложению токен доступа (access token).
5. Используя токен, приложение авторизуется на сервере API и получает доступ к запрашиваемым пользовательским ресурсам.

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

Resource owner password credentials flow

По текущим рекомендациям безопасности описанных в

, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.

Абстрактный oauth 2.0. flow c применением access token

Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.

Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.

Клиент получает одобрение от resource owner, на основе которого ему выдаётся доступ к ресурсу. Всё просто. А будет ли так же просто, если мы добавим в эту схему работу с refresh token?

Абстрактный oauth 2.0. flow c применением refresh token

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

Схема подробнее:

Авторизация с помощью cookies

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

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

Рис.8.5. Cookie изнутри.

Врезка

Директивы apache для контроля доступа

Контроль по IP

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

Внимание! Если вы хотите использовать эти директивы в файле .htaccess, проверьте, что бы для вашего хоста директива AllowOverride корневого файла конфигурации Apache включала опцию Limit

Order

Значения: Order (allow,deny | deny,allow)

Директива Order указывает порядок, в котором будет производиться чтение из директив Allow и Deny

* Allow,deny – сначала читаются директивы Allow. Если пользователя нет в этом списке, то он блокируется. Если же он есть, то далее считываются директивы Deny(процесс еще не закончен). Если же пользователь есть и там, то он блокируется. Если его там нет, то он пропускается. Т.е пользователь пропускается только при наличии только в списке Allow, но не в Deny* Deny,allow – сначала обрабатываются директивы Deny и отсеиваются те пользователи, которые есть в этом списке. Любые другие пропускаются. Т.е пользователь пропускается всегда, но если его нет в списке Deny

Allow и Deny

Формат директив: (Allow | Deny) from (IP | IPs | all) (IP | IPs | all) : (IP | IPs | all)

Директивы Allow и Deny определяют клиентов, которым разрешить или запретить доступ к серверу.

Директивы допускают использование:

* Одиночного IP(IP) – обычный вид IP, например, 127.0.0.1* Группы IP(IPs) – группа IP, например, для доступа, только из локальной сети, 192.168.1.0/24* Любого IP(all) – обозначает любой IP

После слова from может идти любое количество указанных директив, разделенных пробелом

Примеры

Файл .htaccess

В этом файле указывается доступ только для клиентов из локальной сети или с IP 11.11.11.12

Задача auth

Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «

». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных. 

У сервиса Auth есть три основные задачи:

Используемые роли в oauth 2

В рамках описываемого протокола выделяются следующие типы ролей:

• владелец (пользователь): авторизует клиентское приложение на доступ к данным своего аккаунта;
• сервер ресурсов/API: здесь располагаются данные пользовательских аккаунтов, а также бизнес-логика авторизации, отвечающая за выдачу новых OAuth-токенов и проверку их подлинности при обращении клиентских приложений к ресурсам. Целесообразно объединять эти роли, так как физически это один сервис;
• клиентское приложение: собственно сервис, которому пользователь делегирует права доступа к своим данным на сервере ресурсов. Пользователь должен авторизовать приложение, а со стороны сервера API оно должно получить подтверждение в виде ключа (токена) доступа. 

Как работает oauth 2: от запроса на авторизацию до генерации токена

Рассмотрим схему, описывающую принцип действия протокола.

Выделим следующие шаги:

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

В зависимости от бизнес-логики клиентского приложения последовательность шагов может меняться. Далее рассмотрим наиболее распространенные примеры использования OAuth 2.

Минусы

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

Обновление доступа

Как можно было видеть в предыдущих примерах, вместе с токеном при успешной авторизации возвращается также и ключ для обновления доступа (refresh_token). Он может использоваться для обновления токена по окончании его срока жизни, а также принудительного обновления во избежание компрометации токена при его передаче по открытым каналам. В случае успешного обновления доступа сервер API перевыпустит не только access, но и refresh_token.

Плюсы

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

Права доступа

Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.

Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee — доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.

В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII — ” и .

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

Преимущества и недостатки oauth 2

Рассмотрим подробнее плюсы и минусы протокола авторизации.

Пример реализации протокола на php

Рассмотрим живой пример проекта клиент-серверного стороннего приложения, взаимодействующего по API с сервисом Google Таблицы.

Проблемы

Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.

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

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0. 

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

Различия протоколов openid и oauth 2

Основное различие между этими двумя протоколами состоит в цели использования. Так, OpenID служит для аутентификации, то есть подтверждения личности пользователя в клиентском сервисе. Например, вы можете авторизоваться в любом из сервисов Google под своим аккаунтом и работать с ними от своего имени, со своими данными.

Для верификации пользователя OpenID использует ID учетной записи у провайдера, а OAuth — авторизационные ключи (токены) с предопределенным сроком действия и правами доступа.

Регистрация клиента

Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от

фантазии

конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.

Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:

Сессии

“Сессия” — несколько абстрактное понятие, означающее нечто вро-де “законченного периода работы с сайтом”. Например, в сессию могут входить такие действия, как “приход на сайт — загрузка данных — уход с сайта”. Иногда определения сессии разнятся в своей форму-лировке, но суть примерно такая.

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

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

Рис.8.7. Файлы с данными сессий

в папке временных файлов сервера.

Имена файлов соответствуют идентификаторам сессий.

Рис.8.8. Содержимое одного из таких файлов.

В сессии сохранены переменные: legus, wq1, wq2, wq3.

Если у посетителя браузер принимает cookie, то ему высылается cookie (с определенным именем — по умолчанию “PHPSESSID”), со-держащий так называемый “идентификатор сессии” (рис.8.9), а если нет, то web-сервер автоматически помещает данный идентификатор в переменную PHPSESSID в каждую ссылку (рис.8.10) на выдаваемых посетителю страницах сайта (естественно, “внутреннюю” — то есть ве-дущую на другие страницы того же самого сайта, с тем же самым до-менным именем).

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

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

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

Бесспорно, набор сохраненных переменных, относящихся к одной сессии, будет существовать на сервере не вечно. В параметрах файла конфигурации PHP — php.ini — указывается, какое время жизни уста-навливается для cookie с идентификатором сессии (по умолчанию 0 — то есть до закрытия окна браузера и всех открытых из него окон), а также через какое время данные сессий из папки временных файлов удаляются физически (рис.8.11).

Кроме того, существует специальная команда “разрушения сессии”, которая при своем выполнении унич-тожает сохраненные в папке временных файлов данные сессии и тем самым делает недействительным идентификатор сессии. Параметры устанавливаемых cookie, в частности, их “время жизни” также можно задать специальной командой в сценарии на PHP, однако время хра-нения данных сессии в папке временных файлов определяется пара-метром в php.ini, так что при использовании виртуального хостинга вам не всегда удастся настроить работу с сессиями полностью так, как вам бы хотелось.

Рис.8.11. Файл php.ini, раздел настроек параметров сессий.

Чтобы использовать в сценарии на странице возможности работы с сессиями, необходимо включить в него команду session_start() (Так как при работе с сессиями используются cookie, то данная команда должна находиться в начале страницы, перед какими-либо выводимыми в браузер данными), — как при первоначальной установке перемен-ных, так и при последующей работе с ними (Если в файле php.ini установлен в 1 параметр session.auto_start, то это делать не обязательно).

Чтобы указать, какие переменные следует сохранять в качестве данных сессии, следует ис-пользовать команду session_register(“имя первой пере-менной”, “имя второй переменной”,… и т.д.), а чтобы закрыть сессию — команду session_destroy(). При закрытии сес-сии переменные, переданные сценарию с ее помощью, не обнуляются (последнее делает команда session_unset();), так что их можно использовать и в остальной части сценария.

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

Структура проекта

Проект имеет следующую структуру:

Теория

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

Понятия “аутентификация” и “авторизация” часто употребляются как синонимы, но на самом деле они обозначают два разных процесса.

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

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

Признаки аутентификации:

Признаки авторизации:

Таким образом, для доступа к приложению требуется как аутентификация, так и авторизация. Если пользователь не может подтвердить свою личность (идентичность, identity), он не будет иметь доступа. И даже если пользователь подтвердил свою личность, но не авторизовался, в доступе ему будет отказано.

Токен

Под токеном в рамках настоящей статьи подразумевается JSON Web Token.

JWT — это открытый стандарт (RFC 7519), определяющий компактный и автономный способ безопасной передачи данных между сторонами в виде объекта формата JSON. JWT — это стандарт, т.е. все JWT являются токенами, но не все токены являются JWT.

Токены

Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

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

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Вместо вывода

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

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.

Полезные ссылки:

Заключение

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

Автор текста: Роман Андреев.