OAuth — это сокращенное название технологии Open Authorization, что переводится как открытая авторизация. На сегодняшний день вторая версия технологии является наиболее популярной и используется с целью реализации авторизации и аутентификации клиентов в веб-приложениях. Большинство современных фронт-энд разработчиков способны реализовать стратегию аутентификации на клиентской стороне. В данном материале рассмотрим, как работает аутентификация с использованием Open Authorization с технической точки зрения и способы реализации стратегии OAuth 2.0.
Часто данные термины в непрофессиональной среде используются как синонимы и являются взаимозаменяемыми. Однако с технической точки зрения они обозначают два разных процесса, которые обеспечивают контроль доступа в веб-приложениях.
Под аутентификацией понимается проверка личности пользователя, которая, как правило, включает в себя прием на сервер информации с паролем и логином пользователя и дальнейшую ее проверку на соответствие с уже имеющейся информацией в базе данных или на стороннем ресурсе. В качестве примера, рассмотрим службу электронной почты. Для входа в почтовый ящик пользователю необходимо ввести свои учетные данные, которые передаются на сервер. ПО на сервере производит проверку информации с данными, которые имеются в базе. В случае совпадения, пользователю открывается доступ к личному кабинету. В противном случае запрос отклоняется.
Авторизация — вспомогательный процесс, который позволяет определить права доступа уже аутентифицированного клиента к тем или иным действиям или ресурсам. Он подразумевает использование ролей пользователей. В зависимости от роли, клиенту доступны определенные возможности.
Например, в веб-приложении может быть аутентифицировано два пользователя с разными ролями: клиент и администратор. Клиент не должен иметь доступа к администрированию, а администратор получает доступ к панели управления ресурсом и возможность регулировать параметры работы приложения.
Протокол Oauth 2.0 регламентирует взаимодействие одного клиента с двумя интернет-приложениями. Технология позволяет предоставлять ограниченный доступ стороннему приложению к защищенной клиентской информации без необходимости передачи ему данных аутентификации пользователя.
Для полного понимания технологии необходимо рассмотреть ее с разных точек зрения: пользователя и разработчика.
В качестве примера рассмотрим абстрактное приложение «image-upload», основной функцией которого является автоматическая публикация раз в два дня изображений в социальной сети от имени пользователя. Если программа написана с реализацией протокола Open Authorization ниже второй версии, то каждый раз перед публикацией изображений она будет запрашивать учетные данные пользователя для входа в аккаунт. OAuth 2.0 позволяет автоматизировать этот процесс следующим образом:
при первом входе в программу «img-uploader» пользователь будет перенаправлен на страницу социальной сети, где необходимо войти в аккаунт, введя логин и пароль;
после успешного входа на страницу социальная сеть перенаправит пользователя на окно, в котором будет предложено разрешить доступ стороннему приложению (в нашем случае «img-uploader») к некоторой информации, сохраненной в учетной записи. Приложению, в свою очередь, необходимо сообщить социальной сети, к каким ресурсам требуется доступ. В случае с «img-uploader», таким ресурсом являются фотографии.
Пример запроса на доступ к Google-аккаунту от стороннего ПО
После согласия пользователя, социальная сеть создает токен доступа (access token) и псевдопароль для использования приложением загрузки изображений, чтобы получить доступ к ресурсам аккаунта клиента и выгрузить фото.
Чтобы отозвать предоставленный ранее доступ, необходимо в социальной сети аннулировать токен, по которому производится авторизация. При попытке загрузить изображение по недействительному токену приложение получит сообщение об ошибке авторизации.
OAuth 2.0 позволяет не только автоматизировать процесс, но и повышает уровень безопасности клиентских данных при установлении доступа сторонним программным обеспечением. Раньше для этого требовалось вводить учетные данные, сторонние программы получали доступ ко всем ресурсам и могли выполнять любые задачи, предусмотренные социальной сетью.
Так существенно повышался риск утечек данных и взлома учетных записей пользователей, если в стороннее ПО был вшит вредоносный код. По этой причине в прошлом многие веб-приложения избегали интеграции с меньшими приложениями, чтобы обезопасить своих клиентов. Так было и с социальной сетью Facebook.
Вторая версия Open Authorization обеспечивает доступ только к минимальному количеству клиентской информации, необходимой для выполнения ограниченного списка задач, на которые пользователь дает согласие при использовании. Таким способом повышается уровень конфиденциальности информации и безопасности клиентов, так как позволяет контролировать, к каким данным будет иметь доступ стороннее ПО. Это также упрощает взаимодействия между двумя веб-приложениями, делая его проще и безопаснее.
В данном случае рассмотрим идентичное приложение для загрузки изображений «img-uploader» с точки зрения разработчиков. Это позволит понять, как происходит процесс интеграции веб-приложений, и каким образом ПО удается получить доступ к ограниченному кругу пользовательской информации при использовании технологии OAuth 2.0.
Рассмотрим всех участников процесса открытой авторизации. К ним относятся:
Владелец веб-приложения. Это организация или физическое лицо, которые являются владельцами учетной записи в социальной сети, к которой программа «img-uploader» пытается подключиться. Например, это может быть любой пользователь соцсети, который принял решение автоматизировать регулярное добавление фотографий на страницу при помощи стороннего приложения.
Клиент. Это служба или приложение, выполняющая определенную задачу, для которой необходимо подключения к учетной записи пользователя. В данном примере клиентом является программа «img-uploader», выгружающая фотографии на страницу пользователя от его имени. В роли клиента может выступать не только веб-приложение, но и мобильное ПО либо иной программный модуль, в котором предусмотрено взаимодействие по протоколу открытой авторизации.
Сервер авторизации. Он выполняет несколько основных функций, в частности аутентифицирует пользователя на ресурсе. Если вход в аккаунт прошел успешно, и пользователь подтвердил намерение предоставить доступ к личной информацию стороннему приложению, сервер генерирует токен доступа и посылает его программе, выполнившей запрос на его получение. В нашем примере таким сервером является социальная сеть.
Ресурсный сервер. Является хранилищем защищенной информации, базой данных, к которой сервером авторизации предоставляется доступ стороннему приложению от имени владельца аккаунта. В некоторых случаях серверы ресурсов и авторизации — это одна общая машина, но такой подход имеет существенные недостатки. Поэтому в современных ресурсах, например в социальной сети Facebook, они разделены.
Провайдер ресурсов OAuth. Поставщиком услуги открытой аутентификации является владелец сервера авторизации и базы данных. В нашем случае, это социальная сеть.
Совместное функционирование вышеописанных компонентов обеспечивает стандартизированный метод получения доступа к клиентским данным, который не требует от клиента предоставления конфиденциальной информации для входа в аккаунт и обеспечивает высокий уровень безопасности в процессе работы.
Грантами или разрешениями является набор стандартизированных методов, которые используются разработчиками приложения с целью получения сгенерированного сервером токена. Технология OAuth 2.0 предоставляет несколько методов, выбор которых зависит от требований безопасности и вариантов использования. Рассмотрим основные типы грантов:
код устройства;
неявный поток;
код авторизации;
пользовательские учетные данные.
Первое, что необходимо сделать разработчику программы «img-uploader» с поддержкой протокола открытой авторизации второй версии — реализовать регистрацию и аутентификацию «img-uploader» на провайдерском сервере авторизации. Как правило, процесс регистрации включает в себя предоставление следующей информации:
пользовательский идентификатор. Он будет использован поставщиком для хранения клиента в базе данных;
адрес колбека. Представляет собой URL, который будет использован для перенаправления пользователя после того, как от него будет получено согласие на предоставление данных;
список разрешений. В него вносятся действия, которые «img-uploader» будет выполнять от имени пользователя, и данные, к которым приложение получит доступ;
тип ответа. Разработчик может указать тип ответа, который ожидается от провайдера.
После завершения процесса регистрации, провайдером OAuth предоставляются уникальные учетные данные, в числе которых секретный код и идентификатор клиента. В дальнейшем эта информация понадобится для аутентификации пользователя и его авторизации в социальной сети как сторонней программы.
Рассмотрим два наиболее распространенных типа грантов для веб-приложений более подробно.
Данный тип гранта реализуется в пять основных этапов:
Отправка пользователем запроса на сервер авторизации поставщика OAuth для инициации соединения.
Перенаправление серверным ПО приложения клиента на страницу входа для ввода учетной информации.
Вывод окна согласия, в котором указаны действия и ресурсы, к которым программа пытается получить доступ. Пользователь по своему усмотрению выбирает нужные пункты и дает согласие на предоставление информации и выполнение действий.
Пользователь получает от сервера код авторизации, который необходимо отправить обратно вместе с секретным кодом.
Клиент получает сгенерированный токен для доступа к ресурсу.
Алгоритм реализации неявного гранта реализуется аналогичным образом за одним исключением — в нем отсутствует четвертый пункт с обменным кодом авторизации. Чтобы более наглядно проиллюстрировать алгоритм, рассмотрим следующую схему:
Сравнивая два вышеописанных типа грантов, можно сделать вывод, что использование кода авторизации является излишним, так как добавляет дополнительные шаги для получения токена авторизации. Возникает логичный вопрос: почему всегда не использовать неявный поток, если при использовании обоих грантов результат получается идентичным?
Ранее упоминалось, что разные типы разрешений используются в различных ситуациях. Так, поток с кодом авторизации чаще всего применяется для веб-приложений, развернутых на выделенном сервере. Использование кода авторизации существенно повышает уровень безопасности соединения. При использовании неявного потока, клиент получает токен доступа непосредственно в URL-адресе, что делает его уязвимым для перехвата злоумышленниками и вредоносным программным обеспечением.
Чаще всего неявные потоки используются только в веб-приложениях без выделенного сервера. По причине отсутствия собственного сервера, разработчики хранят токены доступа непосредственно в браузере. Однако такой подход является небезопасным. Веб-приложение, реализованные по данному сценарию, не защищены от кибератак с использованием межсайтовых сценариев XSS.
На сегодняшний день специалисты не рекомендуют использовать неявные потоки, и они помечены как устаревшие. Их использование целесообразно только в тех случаях, когда применение других сценариев невозможно по объективным причинам.
На сегодняшний день технология открытой авторизации используется множеством популярных веб-сайтов и социальных сетей, которые предоставляют пользователям возможность использовать свои учетные данные сторонних сервисов для аутентификации. Например, OAuth поддерживает GitHub, Google, Twitter, Facebook, LinkedIn и др.
В данном материале были рассмотрены основные преимущества технологии и ее применение на практике. На сегодняшний день OAuth 2.0 — популярный и сравнительно простой способ реализации авторизации и аутентификации в интернет-приложениях. Простота использования и поддержка технологии крупными IT-компаниями способствуют ее развитию и включению в новые проекты.
