Авторизация через oauth как отключить: OAuth-авторизация — Help Mail.ru. Для разработчиков

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

Определяем термины

Во-первых, давайте определимся с некоторыми ключевыми терминами:

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

API может аутентифицировать, но не разрешит делать определенный запрос.

Последствия нехватки безопасности API

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

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

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

В целом, аутентификация и авторизация с помощью API служат следующим целям:

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

Разные виды авторизации

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

API ключ

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

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

Basic Auth

Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:

Authorization: Basic bG9sOnNlY3VyZQ==

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

Когда сервер API получает сообщение, он дешифрует сообщение и проверяет заголовок. После декодирования строки и анализа имени пользователя и пароля он решает, принять или отклонить запрос.

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Authorization: Basic RnJlZDpteXBhc3N3b3Jk

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

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

Вот диаграмма, отображающая процесс авторизации HMAC:

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

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:

• сервер аутентификации;
• сервер API;
• пользователь или приложение.

Вот базовый процесс Oauth3.0:

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

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer, за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

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

Что документируется в разделе аутентификации

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

Тем не менее нужно объяснить необходимую информацию:

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

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

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

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.

Amazon Web Services

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

Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

👨‍💻 Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

• Какого рода авторизация требуется для отправки запросов к API?
• Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
• Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
• Как информация об авторизации интегрируется в раздел “Начало работы”?

🔙

Go next ➡

защищаем топики Kafka от несанкционированного доступа

Чтобы сделать наши курсы по Apache Kafka еще более полезными, сегодня мы поговорим про базовые и расширенные возможности обеспечения информационной безопасности этой Big Data платформы. А в качестве практического примера разберем кейс международной финтех-компании BlackRock, которая разработала собственное security-решение для Kafka на базе протокола OAuth и серверов единого доступа KeyCloak.

Еще раз о безопасности Apache Kafka: 3 базовых возможности

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

Основными функциями, которые отвечают за безопасность Kafka, являются следующие [1]:

• SSL/TLS-шифрование данных на лету, позволяющий шифровать данные между отправителями (producer) и потребителями (consumer) Kafka. Это шифрование решает проблему атаки «человек посередине», защищая данные по умолчанию в PLAINTEXT от прочтения маршрутизаторами по пути передачи данных в сети интернет. При использовании SSL только первая и последняя машина могут расшифровать отправляемый пакет. Побочным эффектом этой безопасности является незначительное снижение производительности, т.к. теперь ЦП клиентов и брокеров Kafka теперь также используется для шифрования и дешифрования пакетов. Примечательно, что применение более поздних версий Java и самой Apache Kafka существенно снижают эти накладные расходы.
• SSL/SASL-аутентификация, которая обеспечивает проверку продюсеров и потребителей в Kafka-кластере, что необходимо для предоставления им соответствующих прав (авторизаций) для доступа к данным. Суть двухсторонней SSL-аутентификацией в том, что брокеры Kafka проверяют подлинность клиентов по наличию сертификатов, подписанных центром сертификации. SASL (Simple Authorization Service Layer) механизм аутентификации отделен от протокола Kafka и поддерживает несколько вариантов (PLAINTEXT, SCRAM, GSSAPI на базе Kerberos, SASL-расширение с конфигурацией обратных вызовов, OAUTHBEARER). О особенностях SSL/SASL-аутентификация в Apache Kafka мы писали здесь на примере кейса тревел-площадки Booking.com.
• ACL-авторизация, когда после проверки подлинности клиентов брокеры Kafka обращаются к спискам управления доступом (ACL, Access Control Lists), чтобы определить, допущен (авторизован) ли конкретный клиент на запись или чтение в какой-либо топик. Подробнее о том, как работает ACL-авторизация в Apache Kafka мы рассказывали здесь и здесь.

Итак, по умолчанию служба безопасности Kafka использует цифровые сертификаты аутентификации и проприетарные ACL-списки для авторизации. Но эти базовые возможности не покрывают всех потребностей современного бизнеса и не соответствуют последним стандартам корпоративной безопасности. Поэтому инженеры данных и администраторы Big Data кластеров международной финтех-компании BlackRock разработали собственное комплексное и масштабируемое решение для обеспечения безопасности Apache Kafka с минимальной нагрузкой на разработчиков. О том, что именно оно собой представляет, мы поговорим далее.

Комбо аутентификации и авторизации на корпоративном уровне: security-библиотека OAuth

Изначально потребность в расширенных настройках безопасности Apache Kafka у BlackRock возникла в рамках проекта Cachematrix – веб-платформы управления ликвидностью, одобренной 25 крупными глобальными банками и компаниями по управлению активами. Проект имеет многопользовательскую архитектуру, которая требует строгой изоляции обработки данных и контроля доступа к функциям и ресурсам со стороны клиента. Для этого необходимо комплексное и масштабируемое решение с минимальной нагрузкой на разработчиков, включая следующие возможности [2]:

• детальный контроль безопасности для всех ресурсов системы и приложений в Kafka;
• прозрачность элементов управления для разработчиков;
• централизованное управление элементами во время развертывания или в процессе эксплуатации реальной системы (production) с разделением обязанностей;
• поддержка срока действия и обновления учетных данных для длительных процессов без простоев.

Для реализации этих требований специалисты BlackRock разработалии собственную библиотеку на базе стандартной структуры безопасности OAuth, которое обладает следующими функциями и характеристиками:

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

Основой OAuth-библиотеки BlackRock является SASL-платформа самой Кафка и технология единого входа в open-source сервере KeyCloak, который обеспечивает регистрацию пользователей, авторизацию через соцсети, выдачу JSON веб-токенов подлинности аккаунтам, двухфакторная аутентификацию, интеграцию со службами каталогов (LDAP-сервером), брокер Kerberos и другие функции безопасного управления доступом [3].

Apache Kafka предоставляет платформу на основе SASL OAUTHBEARER, который входит в Kafka для реализации пользовательской аутентификации и позволяет разработчикам подключать более сложные службы безопасности корпоративного уровня. OAuth – это общепринятый протоколом безопасности, позволяя сторонним приложениям получать токен для доступа к службе ресурсов. Срок действия токена истекает в течение определенного срока. Когда токен истекает, приложение должно запросить новый токен, чтобы оставаться аутентифицированным. Таким образом, OAuth соответствует требованиям BlackRock для аутентификации и авторизации на корпоративном уровне.

Серверы OAuth позволяют использовать несколько типов учетных данных для защиты приложения. В решении BlackRock используется тип предоставления учетных данных клиента, который обрабатывает взаимодействие между сервисами. Клиент OAuth – это приложение, зарегистрированное на сервере OAuth, например, приложение Kafka с запущенным продюсером, который отправляет данные в топик. В этом случае санкционированный доступ предоставляется следующим образом [2]:

• идентификатор и секрет клиента позволяют получить ему токен с сервера OAuth;
• клиент делает запрос к ресурсу и передает этот токен вместе с запросом;
• ресурс аутентифицирует запрос, проверяя токен на сервере OAuth;
• после аутентификации ресурс определяет разрешения на доступ в токене для авторизации, отправляя токен авторизатору для проверки разрешений;
• для авторизации библиотека переопределяет Authorizer для использования разрешений на доступ OAuth;
• гибкая авторизация выполняется с использованием механизма ACL-списков и возможностей KeyCloak.

Таким образом, решение BlackRock объединяет аутентификацию и ACL-авторизацию в едином рабочем процессе на централизованном сервере OAuth. Исходный код этой security-библиотеки доступен для всеобщего использования на Github [4].

Завтра мы продолжим разбирать опыт BlackRock и рассмотрим на примере их финтех-платформы, почему в микросервисной архитектуре особенно важна конечная согласованность и как ее достичь с помощью Apache Kafka Streams.

Больше подробностей по обеспечению безопасности, разработки распределенных приложений потоковой аналитики больших данных и администрирования кластеров Apache Kafka вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

1. https://medium.com/@stephane.maarek/introduction-to-apache-kafka-security-c8951d410adf
2. https://medium.com/blackrock-engineering/utilizing-oauth-for-kafka-security-5c1da9f3d3d
3. https://ru.wikipedia.org/wiki/Keycloak
4. https://github.com/kafka-security/oauth

Как подключить и отключить двухэтапную авторизацию / Google Authenticator / привязка к телефону

ВАЖНО!

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

Для чего это?

 Для повышения защищенности вашего аккаунта от попыток взлома и кражи, введена система двухэтапной авторизации посредством сервиса Google Authenticator. Система призвана защитить аккаунт, даже если пароль попадёт в руки злоумышленника. Для работы Google Authenticator достаточно смартфона на базе операционной системы iOS, Android или BlackBerry. Существуют также неофициальные приложения для Windows phone.

 Как подключить?

 Для подключения данного типа авторизации вам необходимо иметь смартфон на базе операционной системы iOS, Android или BlackBerry. Для Windows phone существуют неофициальные приложения. Также существует возможность подключения двухэтапной авторизации к регистрационной почте или приложению Gaijin Pass. 

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

WarThunder: Привязка Steam-аккаунта к электронной почте.

Crossout: Как привязать почту к аккаунту (если ранее Вы играли через Steam)

StarConflict: Как привязать почту к аккаунту (если ранее Вы играли через Steam)

CRSED: F.O.A.D.: Как привязать почту к аккаунту (если ранее вы играли через Steam)

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

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

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

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

Шаг 1:

Скачайте и установите подходящее для вашего устройства приложение для получения кодов двухэтапной авторизации.

Ссылки на приложение:

    Android: Google Play
    iPhone: App Store
    Windows Phone (неофициальные приложения во внутреннем магазине)
    BlackBerry (устанавливается через переход на http://m.google.com/authenticator)

Шаг 2:

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

Шаг 3:

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

Шаг 4:

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

Подключение двухэтапной авторизации к почте.

Подключить двухэтапную авторизацию к почте вы можете из личного кабинета на нашем сайте Мой профиль => Безопасность => Защита аккаунта.

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

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

Как отключить двухэтапную авторизацию.

 Данный тип авторизации можно отключить в разделе Мой профиль => Безопасность => Защита аккаунта.

 Далее вам будет необходимо нажать кнопку «Отключить» и ввести код авторизации из приложения на вашем устройстве.

Как можно авторизоваться в сервисах RAMBLER&Co?

Войти на сервисы RAMBLER&Co можно несколькими способами:

• Указав свою электронную почту и пароль

В качестве логина и пароля на форме входа вы можете ввести ваш адрес Рамблер/почты и пароль от нее или адрес зарегистрированной в RAMBLER&Co внешней почты и пароль.

Внимание! При вводе внешней почты надо указывать пароль не от самого почтового ящика, а пароль, придуманный при регистрации этого ящика в RAMBLER&Co.

• C помощью телефона для восстановления доступа к Рамблер/почте

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

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

• Аккаунт в социальной сети (авторизация по протоколу OAuth). Доступны сети: Livejournal, ВКонтакте, Facebook, Одноклассники, Mail.ru, Gmail, Twitter, Instagram, mos.ru.

Нажмите на форме входа кнопку той социальной сети, через которую вы хотите войти. Далее в открывшемся окне соцсети подтвердите возможность пользоваться этой социальной сетью для авторизации на RAMBLER&Co — и мы создадим вам единый профиль в RAMBLER&Co, заполненный на основании полученных от социальной сети данных (см. раздел «Как можно зарегистрировать единый профиль в RAMBLER&Co»). Повторный вход через социальную сеть будет разрешен автоматически.

Пользователи, у которых уже есть единый профиль в RAMBLER&Co, тоже могут присоединить к нему учетные записи социальных сетей, чтобы проходить авторизацию в один клик, не вводя каждый раз логин и пароль (см. раздел «Как привязать профиль в соцсети?»).

Это безопасно, так как пользователь вводит пароль для своего аккаунта в социальной сети на странице этой сети и авторизуется на ресурсах RAMBLER&Co уже после авторизации там. Сервисы и продукты RAMBLER&Co не будут иметь доступ к паролю от вашего аккаунта в соцсети. Также вы можете в любой момент отозвать разрешение использовать соцсеть для авторизации, применив соответствующую настройку в разделе с настройками вашего аккаунта в социальной сети.

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

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

HTTP авторизация — HTTP | MDN

HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространённой схемой HTTP авторизации является «Basic» (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с её использованием.

RFC 7235 определяет средства HTTP авторизации, которые может использовать сервер для запроса у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом 401 (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок WWW-Authenticate, содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок Authorization с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке Authorization.

В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.

Прокси-авторизация

Этот же механизм запроса и ответа может быть использован для прокси-авторизации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса 407 (Proxy Authentication Required) и заголовок Proxy-Authenticate, который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок Proxy-Authorization.

Доступ запрещён

Если (прокси) сервер получает корректные учётные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом 403 Forbidden. В отличии от статус кода 401 Unauthorized или 407 Proxy Authentication Required, аутентификация для этого пользователя не возможна.

Аутентификация с помощью изображений

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

Кодировка символов HTTP аутентификации

Браузеры используют кодировку utf-8 для имени пользователя и пароля. Firefox использовал ISO-8859-1, но она была заменена utf-8 с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как баг 1419658).

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

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

Here, <type> is the authentication scheme («Basic» is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like «Access to the staging site» or similar, so that the user knows to which space they are trying to get access to.

The Authorization and Proxy-Authorization request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Authentication schemes

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

The most common authentication scheme is the «Basic» authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:

The «Basic» HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

Security of basic authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Restricting access with Apache and basic authentication

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

The .htaccess file typically looks like this:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

The .htaccess file references a .htpasswd file in which each line contains of a username and a password separated by a colon («:»). You can not see the actual passwords as they are encrypted (md5 in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn’t be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Restricting access with nginx and basic authentication

For nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Access using credentials in the URL

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

https://username:[email protected]/

The use of these URLs is deprecated. In Chrome, the username:password@ part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt «You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you.».

Авторизация учетных записей разработчиков с помощью OAuth 2.0 в управлении API — Azure API Management

• 14.08.2020
• 5 минут на чтение

В этой статье

Многие API-интерфейсы поддерживают OAuth 2.0 для защиты API и обеспечения доступа только действительных пользователей, а также доступ к ресурсам, на которые они имеют право. Чтобы использовать интерактивную консоль разработчика Azure API Management с такими API, служба позволяет настроить экземпляр службы для работы с вашим OAuth 2.0 включен API.

Предварительные требования

В этом руководстве показано, как настроить экземпляр службы управления API для использования авторизации OAuth 2.0 для учетных записей разработчиков, но не показано, как настроить поставщика OAuth 2.0. Конфигурация для каждого поставщика OAuth 2.0 отличается, хотя шаги аналогичны, и необходимая информация, используемая при настройке OAuth 2.0 в вашем экземпляре службы управления API, одинакова. В этом разделе показаны примеры использования Azure Active Directory в качестве OAuth 2.0 провайдер.

Примечание

Дополнительные сведения о настройке OAuth 2.0 с помощью Azure Active Directory см. В примере WebApp-GraphAPI-DotNet.

Наличие

Важно

Эта функция доступна на уровнях управления API Premium , Standard , Basic и Developer .

Настроить сервер авторизации OAuth 2.0 в API Management

1. Щелкните OAuth 2.0 в меню слева и нажмите + Добавить .

2. Введите имя и дополнительное описание в поля Имя и Описание .

   Примечание

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

3. Введите URL-адрес страницы регистрации клиента .На этой странице пользователи могут создавать свои учетные записи и управлять ими. Эта страница зависит от используемого провайдера OAuth 2.0. URL-адрес страницы регистрации клиента указывает на страницу, которую пользователи могут использовать для создания и настройки собственных учетных записей для поставщиков OAuth 2.0, которые поддерживают управление учетными записями пользователей, например https://contoso.com/login . Некоторые организации не настраивают и не используют эту функцию, даже если поставщик OAuth 2.0 ее поддерживает. Если у вашего поставщика OAuth 2.0 не настроено управление учетными записями пользователей, введите здесь URL-адрес-заполнитель, например URL-адрес вашей компании, или URL-адрес, например https: // placeholder.contoso.com .

4. Следующий раздел формы содержит Типы предоставления авторизации , URL-адрес конечной точки авторизации и Параметры метода запроса авторизации .

   Укажите Типы разрешений на авторизацию , отметив нужные типы. Код авторизации указан по умолчанию.

   Введите URL-адрес конечной точки авторизации . Для Azure Active Directory этот URL-адрес будет аналогичен следующему URL-адресу, где заменяется идентификатором вашего клиента Azure AD.

   https://login.microsoftonline.com//oauth3/authorize

   Метод запроса авторизации определяет, как запрос авторизации отправляется на сервер OAuth 2.0. По умолчанию выбрано GET .

5. Затем необходимо указать URL-адрес конечной точки маркера , Методы аутентификации клиента , Метод отправки маркера доступа и Необходимо указать область действия по умолчанию .

   для Azure Active Directory OAuth 2.0, URL-адрес конечной точки токена будет иметь следующий формат, где имеет формат yourapp.onmicrosoft.com .

   https://login.microsoftonline.com//oauth3/token

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

6. Раздел Учетные данные клиента содержит идентификатор клиента и секрет клиента , которые получаются в процессе создания и настройки вашего сервера OAuth 2.0. После указания идентификатора Client ID и Client secret генерируется redirect_uri для кода авторизации . Этот URI используется для настройки URL-адреса ответа в конфигурации вашего сервера OAuth 2.0.

   В новом портале разработчика суффикс URI имеет вид:

   • / signin-oauth / code / callback / {authServerName} для потока предоставления кода авторизации
   • / signin-oauth / implicit / callback для неявного потока предоставления

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

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

Настроить API для использования авторизации пользователя OAuth 2.0

1. Щелкните APIs в меню API Management слева.

2. Щелкните имя нужного API и щелкните Настройки .Прокрутите до раздела Security , а затем установите флажок для OAuth 2.0 .

3. Выберите нужный Сервер авторизации из раскрывающегося списка и нажмите Сохранить .

Устаревший портал разработчика — проверьте авторизацию пользователя OAuth 2.0

Примечание

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

После того, как вы настроили сервер авторизации OAuth 2.0 и настроили API для использования этого сервера, вы можете протестировать его, перейдя на портал разработчика и вызвав API. Щелкните Портал разработчика (устаревшая версия) в верхнем меню на странице «Обзор » экземпляра управления API Azure. .

Щелкните API в верхнем меню и выберите Echo API .

Примечание

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

Выберите операцию GET Resource , щелкните Открыть консоль , а затем выберите Код авторизации из раскрывающегося списка.

При выборе Код авторизации отображается всплывающее окно с формой входа поставщика OAuth 2.0.В этом примере форма входа предоставляется Azure Active Directory.

Примечание

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

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

На этом этапе вы можете настроить желаемые значения для остальных параметров и отправить запрос.

Следующие шаги

Для получения дополнительных сведений об использовании OAuth 2.0 и управления API см. Следующее видео и сопутствующую статью.

Почему вам следует прекратить использование неявного предоставления OAuth! | Торстен Лоддерштедт | OAuth 2

Никто больше не должен использовать неявное предоставление! Это то, что рабочая группа IETF OAuth, отвечающая за официальные спецификации OAuth, рекомендует в готовящемся к выпуску RFC OAuth 2.0 Security Best Current Practice.Решение было принято на заседании IETF на этой неделе в Бангкоке.

Вот что говорится в документе рабочей группы:

Неявное предоставление (тип ответа «токен») и другие типы ответов, заставляющие сервер авторизации выдавать токены доступа в ответе авторизации, уязвимы для утечки токена доступа и воспроизведения токена доступа. …

Во избежание этих проблем клиентам НЕ СЛЕДУЕТ использовать неявное предоставление и любой другой тип ответа, заставляющий сервер авторизации выдавать маркер доступа в ответе авторизации.

Звучит довольно резко, в чем причина?

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

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

Это смертельный удар для OAuth?

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

Это косвенное обращение имеет огромные преимущества в плане безопасности: коды авторизации могут быть недолговечными и одноразовыми, а сервер авторизации может аутентифицировать клиентов, что значительно снижает поверхность атаки. Он также позволяет обнаруживать все виды вредоносных атак, которым подвержены перенаправления HTTP, особенно инъекции.В предстоящем выпуске протокола безопасности OAuth BCP это подробно объясняется.

Но какого черта рабочая группа OAuth вообще изобрела этот неявный грант?

Что ж, в старые времена (еще в 2010 году) браузерные приложения были ограничены отправкой запросов только на свой сервер. Таким образом, не было возможности вызвать конечную точку токена сервера авторизации на другом хосте. Вот почему было введено сокращение для доставки токена доступа в ответе авторизации через браузер. Риски, связанные с этим подходом, следует снизить за счет ограничения привилегий и времени жизни таких токенов.Неявный грант всегда был компромиссом!

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

Также началась работа над RFC передовой практики для браузерных приложений. Если вы хотите внести свой вклад, отправьте сообщение в список рассылки OAuth.

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

Общие сведения о том, как Access Manager использует OAuth и OpenID Connect

ПРИМЕЧАНИЕ. NTS будет поддерживать настройку Access Manager и любые проблемы с приложением, когда запрос API отправляется на правильную конечную точку Access Manager. Любые другие изменения кода, необходимые для интеграции с Access Manager, выходят за рамки традиционной поддержки NTS и должны проходить через канал [email protected].

Ниже приведена последовательность настройки OAuth и OpenID Connect:

ПРИМЕЧАНИЕ. Используйте Internet Explorer 10 или новее, Firefox или Chrome для настройки OAuth 2.0.

Включение OAuth и OpenID Connect

Чтобы использовать OAuth, необходимо включить его в Identity Server. В противном случае конфигурация работать не будет.

Чтобы включить OAuth и OpenID Connect, выполните следующие действия:

1. Щелкните>>.

2. В разделе выберите.

3. Щелкните.

4. Обновите сервер идентификации.

ПРИМЕЧАНИЕ: Для авторизации OAuth, поставщик удостоверений и ESP должны быть включены с SSL.

Расширение хранилища пользователей для информации о предоставлении авторизации OAuth 2.0

  {
    "access_token": "xoxp-23984754863-2348975623103",
    "scope": "читать"
}
  

  {
    "access_token": "xoxp-XXXXXXXX-XXXXXXXX-XXXXX",
    "scope": "incoming-webhook, commands, bot",
    "team_name": "Команда устанавливает ваш крючок",
    "team_id": "XXXXXXXXXX",
    "incoming_webhook": {
        "url": "https: // крючки.slack.com/TXXXXX/BXXXXX/XXXXXXXXXX ",
        "channel": "# channel-it-will-post-to",
        "configuration_url": "https://teamname.slack.com/services/BXXXXX"
    },
    "bot": {
        "bot_user_id": "UTTTTTTTTTTR",
        "bot_access_token": "xoxb-XXXXXXXXXXXX-TTTTTTTTTTTTTT"
    }
}
  

  http://yourapp.com/oauth?
  error = access_denied
  

  ПОЛУЧИТЬ /api/conversations.list?limit=50
Авторизация: предъявитель xoxb-1234-abcdefgh
  

  ПОЛУЧИТЬ /api/conversations.list?limit=50&token=xoxb-1234-abcdefgh
  

  ЗАПИСЬ /api/conversations.list
Тип содержимого: приложение / x-www-form-urlencoded
токен = xoxb-1234-abcdefgh & limit = 50
  

  ОБРАТНЫЙ ЗВОНОК: http://example.com/path

ХОРОШО: https://example.com/path
ХОРОШО: http://example.com/path/subdir/other
ПЛОХО: http://example.com/bar
ПЛОХО: http://example.com/
ПЛОХО: http://example.com:8080/path
ПЛОХО: http://oauth.example.com:8080/path
ПЛОХО: http: // example.орг
  

  X-OAuth-Scopes: identity.basic, реакции: читать
  

  Базовый <имя пользователя и пароль в кодировке Base64>  

 https://github.com/login/oauth/authorize?realm=Employees 

 https://github.com/login/oauth/authorize?realm=Employees?client_id=XXXXXXXXXXXX&scope=openid%20profile%20email 

 расположение ~ (/ artifactory / webapp / | / artifactory / ui / | / artifactory / api / oauth3 /) {
        proxy_http_version 1.1;
        proxy_pass http: // ;
        proxy_intercept_errors on;
        proxy_pass_header Сервер;
        proxy_connect_timeout 75 с;
        proxy_send_timeout 2400 сек;
        proxy_read_timeout 2400 сек;
        proxy_set_header Host $ host;
        proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $ http_x_forwarded_proto;
        proxy_set_header X-Real-IP $ remote_addr;
        proxy_set_header X-JFrog-Override-Base-Url $ http_x_forwarded_proto: // $ host;
}