OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки / Хабр

Почему oauth, а не виджет «войти через»?

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

Почему oauth, а не openid?

Потому что OpenID практически бесполезен для тех целей, для которых декларирован. Это сугубо мое мнение, но оно опирается не на пустое место.

Во-первых, OpenID пользуются в основном «гики», процент которых в интернете не настолько высок, чтобы перестраивать под них сайты (за некоторым исключением, разумеется 🙂 ) Почему так? Потому что для того, чтобы получить OpenID аккаунт, надо — его получить.

Зайти на OpenID сервер и предпринять некоторые действия, чтобы заполучить некий, довольно невразумительный, набор символов. Который, несмотря на сложность (для простого пользователя) надо не забыть и вводить при случае, если на глаза попадется знакомая пиктограмма

. Ну какой казуальный пользователь будет это делать? А с OAuth все намного проще — видит человек кнопку «Войти через ВКонтакте», нажимает, и… уже на сайте с правами зарегистрированного пользователя. «Будьте проще», — говорил классик, — «и люди к вам потянутся». Как в воду глядел.

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

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

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

Кроме того, OpenID аутентификация, в сущности, не дает никаких гарантий клиенту. Она подтверждает лишь, что запрашиваемый пользователь действительно зарегистрирован на одном из OpenID-серверов — и все. Механизмы получения дополнительной информации о пользователе (email, имя, возраст) имеются, но мало кем поддерживаются.

Можно, конечно, в нарушение идей OpenID, анализировать идентификатор и доверять только определенным OpenID-провайдерам (например, тем же социалкам). Но смысл, если почти все из них (за исключением ЖЖ, но он и по OpenID ровным счетом ничего не расскажет о пользователе)

Basic авторизация

Данный вид авторизации чаще всего используется браузером для доступа к функциям API.

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

Authorization: Basic {login}:{password}

Допускается base64 при формировании строки {login}:{password}

Google

1. Идем

. Создаем новый проект. На вкладке API access нажимаем кнопку «Create an OAuth2 client ID».

Получаем client_id(Client ID) и secret_key(Client Secret).

2. Код кнопки должен быть вида:

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

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

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

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

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

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

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

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

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

Авторизация методом get

Еще один способ авторизации — отправить GET запрос по адресу /api/v1/session, при этом в url запросе указать параметры login и password:

Валидация при регистрации

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

Вконтакте

1. Идем

. Тип — «Веб-сайт». Вводим базовый домен и адрес сайта. На странице настроек получаем client_id (ID приложения) и secret_key (защищенный ключ).

2. Втыкаем в код кнопку вида

Восстановление после окончания срока действия сессии

Восстановление после окончания срока действия сессии происходит путем отправки refresh_token на сервер, в результате приходит новый access_token и refresh_token

Пример:

Вызов функций с использованием token

Для того чтобы обратиться к функциям (если не используется Basic авторизация), для которых необходима авторизация, необходимо в заголовке Authorization передавать токен:

Authorization: Bearer <token>

Иначе сервер вернет ошибку авторизации 401.

Дайджест-аутентификация (digest)

Дайджест-аутентификация – более безопасная и надежная альтернатива простой, но небезопасной базовой аутентификации.

Итак, как это работает?

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

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

Добавляем соль

На самом деле md5 не дает полной защиты от расшифровки.

В случае простого или очень популярного пароля хеш элементарно расшифровывается с помощью гугла.

Изменить права доступа (scope)

1. Получите id вашего токена:
2. В ответе придёт массив scope — список текущих прав и id вашего токена.
3. Используйте id токена, чтобы изменить права доступа. В теле запроса укажите все права для токена. Например, если добавляете права доступа, то в теле запроса должны быть и существующие права и новые.
4. В ответ вернётся сообщение о перезаписи прав доступа токена:

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

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

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

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

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

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

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

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

Как это работает.

Если кому интересны все подробности, то см. ссылки выше. А вкратце — так:

Краткое резюме

Как видите, дайджест-аутентификацию сложнее понять и реализовать.

Она также более безопасна, чем обычная проверка подлинности, но все же уязвима для атаки “человек посередине”. RFC 2617 рекомендует использовать вместо этого дайджест-аутентификацию базовой аутентификации, поскольку она устраняет некоторые ее недостатки.

Итак, вкратце дайджест-аутентификация:

• Не отправляет пароли в виде обычного текста по сети.
• Предотвращает повторные атаки
• Защита от подделки сообщений

Некоторые из слабых мест:

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

В связи с этим дайджест-аутентификация пока не получила широкого распространения. Базовая аутентификация намного проще и в сочетании с SSL еще более безопасна, чем дайджест-аутентификация.

Минусы

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

Области безопасности

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

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

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

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

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

Одноклассники

1. Регистрируемся как разработчик

. Идем

и заполняем заявку на получение OAuth доступа. Н-да. Заявка, похоже, обрабатывается вручную. Если ответа в течение суток нет, пинаем поддержку по тому же адресу. «Одноклассники», что тут скажешь…

2. Получаем письмо с инструкциями и, следуя им, заполняем форму.

Все заполненные в примере поля обязательны к заполнению. Нажимаем «Сохранить» и получаем письмо на указанный емайл, содержащее client_id(Application ID), public_key(Публичный ключ приложения) и secret_key(Секретный ключ приложения)

3. Код кнопки должен быть вида:

Плюсы

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

Подробное объяснение

Давайте определим это:

Атрибут ответа рассчитывается следующим образом:

Получить информацию о клиентах приложения

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

Пример запроса:

Параметры запроса:

Пример ответа:

{"items":[{"client_id":"89856c66-c9d1-4fad-996e-71fa368179ee","client_secret":"44c8fa46-af2d-47c3-b440-e2b82963ea0e","scope":["device:read"],"authorized_grant_types":["implicit","authorization_code"],"registered_redirect_uri":["<redirect_url>"],"access_token_validity":604800,"publisher_id":"2d0c2b00-b843-45f1-97d2-2276e52fe469","app_id":"fabd6e93-9dcd-46d7-a4ca-3f9d8fc0a441","version_id":"0.1"}],"paging":{}}

Практические рекомендации по реализации

Разумеется, в первую очередь надо зарегистрироваться в соцсети, активировать аккаунт, ну и всё такое. Не торопиться. Некоторые сервера не сразу корректно обрабатывают запросы от свежезарегистрированных OAuth-клиентов. Здесь я расписал только успешные потоки, забывать про обработку ошибок — никак не стоит.

Также я практически не уделил внимания аспектам безопасности — это тема отдельной статьи. Как минимум, везде, где можно передавать уникальный параметр в callback-url для каждого пользователя — это стоит делать (Основной callback адрес должен оставаться без изменений, а меняться — только параметр, иначе сервер не пропустит запрос.

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

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

Пример digest authentication

1. Пользовательский клиент -> Сервер

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

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

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

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

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

Связанные с аутентификацией заголовки запросов/ответов

Сервер выдает запрос, используя заголовок ответа WWW-Authenticate. Он содержит информацию о протоколе и области безопасности.

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

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

Список прав доступа к ресурсам (scope)

Права доступа к ресурсам задаются в массиве scope при создании настроек авторизации. Например:

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

Структура аутентификации запроса/ответа

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

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

Форма авторизации на простом 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

Шаг 2. создайте настройки авторизации через oauth

Создаёт клиента приложения с определённым набором прав доступа к ресурсам пользователя. Параметр version-id содержит идентификатор версии приложения.

Идентификатор версии приложения отображается в адресной строке браузера при выборе версии приложения на портале разработчиков.

Пример запроса:

Параметры запроса:

Шаг 4. авторизуйте пользователя

Используя параметр code с шага 3, создайте access_token для пользователя:

Пример ответа:

Параметры ответа:

Яндекс

1. Идем