Содержание

Поток кода авторизации OAuth 2.0 и платформа удостоверений Майкрософт — Microsoft identity platform

  • Чтение занимает 19 мин

В этой статье

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

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

Описание потока кода авторизации OAuth 2.0 см. в разделе 4.1 спецификации OAuth 2.0. Он используется для проверки подлинности и авторизации большинства типов приложений, в том числе одностраничных приложений, веб-приложений и собственных приложений. Поток позволяет приложениям безопасно получать access_tokens, которые можно использовать для доступа к ресурсам, защищенным платформой Microsoft Identity, а также обновлять маркеры для получения дополнительных access_tokens и маркеров идентификации для пользователя, выполнившего вход.

Схема протокола

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

Для одностраничных приложений требуется настройка URI перенаправления

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

Чтобы обновить существующий URI перенаправления, чтобы включить CORS, откройте редактор манифеста и задайте type поле для URI перенаправления spa в replyUrlsWithType разделе. Можно также щелкнуть URI перенаправления в разделе «веб» на вкладке «Проверка подлинности» и выбрать URI, на которые требуется выполнить миграцию, с помощью потока кода авторизации.

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

Если при попытке использовать поток кода авторизации отображается следующая ошибка:

access to XMLHttpRequest at 'https://login.microsoftonline.com/common/v2.0/oauth3/token' from origin 'yourApp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Затем откройте регистрацию приложения и обновите URI перенаправления для своего приложения, чтобы ввести spa .

Запрос кода авторизации

Поток кода авторизации начинается с того, что клиент направляет пользователя к конечной точке /authorize . В этом запросе клиент запрашивает у пользователя разрешения openid, offline_access и https://graph.microsoft.com/mail.read . Некоторые разрешения имеют только администраторы, например запись данных в каталог организации с помощью

Directory.ReadWrite.All. Если приложение запрашивает доступ к одному из таких разрешений у корпоративного пользователя, появится сообщение об ошибке со сведениями о том, что этот пользователь не может предоставить разрешения приложению. Чтобы запросить доступ к областям, ограниченным администратором, необходимо запросить их непосредственно у глобального администратора. Дополнительные сведения см. в статье Разрешения, предназначенные только для администраторов.

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth3/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256

Совет

Чтобы выполнить этот запрос, щелкните ссылку ниже! После входа браузер будет перенаправлен по адресу https://localhost/myapp/, при этом в адресной строке будет указано code. https://login.microsoftonline.com/common/oauth3/v2.0/authorize…

Параметр Обязательный или необязательный Описание
tenant обязательно Значение {tenant} в пути запроса можно использовать для того, чтобы контролировать, кто может входить в приложение.
Допустимые значения: common, organizations, consumers, а также идентификаторы клиента. Дополнительные сведения см. в описании протоколов.
client_id обязательно Идентификатор приложения (клиента) , назначенный вашему приложению функцией Регистрация приложений портала Azure.
response_type обязательно Должен содержать code для потока кода авторизации. Может также включать id_token или token при использовании гибридного потока.
redirect_uri обязательно URI перенаправления приложения, на который можно отправлять ответы проверки подлинности для их получения приложением. Он должен в точности соответствовать одному из URI перенаправления, зарегистрированных на портале, но иметь форму закодированного URL-адреса. Для собственных & мобильных приложений следует использовать одно из рекомендуемых значений —
https://login. microsoftonline.com/common/oauth3/nativeclient
(для приложений, использующих встроенные браузеры) или http://localhost (для приложений, использующих системные браузеры).
scope обязательно Разделенный пробелами список областей , для которого необходимо согласие пользователя. Для части /authorize запроса это может охватывать несколько ресурсов, позволяя приложению получить согласие на несколько веб-интерфейсов API, которые требуется вызвать.
response_mode рекомендуется Указывает метод, с помощью которого результирующий маркер будет отправлен приложению. Может применяться один из перечисленных ниже типов.

query
fragment
form_post

query предоставляет код в качестве параметра строки запроса в URI перенаправления. Если с помощью неявного потока запрашивается маркер идентификации, использовать query нельзя (как описано в спецификациях OpenID). Если запрашивается только код, можно использовать query, fragment или form_post. form_post выполняет запрос POST, который содержит код для URI перенаправления.

state рекомендуется Значение, включенное в запрос, которое также возвращается в ответе маркера. Это может быть строка любого контента. Как правило, для предотвращения подделки межсайтовых запросовиспользуется генерируемое случайным образом уникальное значение. Также в этом значении кодируются сведения о состоянии пользователя в приложении перед выполнением запроса на аутентификацию. Например, это могут быть сведения об открытой на тот момент странице или представлении.
prompt необязательный Указывает требуемый тип взаимодействия с пользователем. На текущий момент единственные допустимые значения — login, none и consent.

При значении — prompt=login пользователю придется вводить учетные данные по запросу. Единый вход не сработает.
Значение — prompt=none

является противоположным — оно гарантирует, что интерактивные запросы не будут выводиться ни при каких обстоятельствах. Если запрос не может быть выполнен автоматически с помощью единого входа, платформа Microsoft Identity возвратит interaction_required ошибку.
Если установить значение — prompt=consent, то после входа пользователь увидит диалоговое окно согласия OAuth с запросом на предоставление разрешений приложению.
prompt=select_account приведет к прерыванию единого входа, предоставляя возможность выбора учетной записи из списка всех учетных записей в сеансе или любой сохраненной учетной записи, или возможность использовать совершенно другую учетную запись.

login_hint необязательный Можно применять для предварительного заполнения поля имени пользователя или адреса электронной почты на странице входа пользователя (если имя пользователя известно заранее).
Зачастую этот параметр используется в приложениях при повторной проверке подлинности. При этом имя пользователя извлекается во время предыдущего входа с помощью утверждения preferred_username.
domain_hint необязательный Если указан этот параметр, пропускается процесс обнаружения на основе электронной почты, который нужно проходить на странице входа в приложение версии 2.0. Это несколько упрощает взаимодействие с пользователем (например, отправляя их к поставщику федеративных удостоверений.) Обычно этот параметр применяется в приложениях при повторной аутентификации. Для этого значение утверждения tid извлекается из предыдущего сеанса входа. Если значение утверждения tid
9188040d-6c67-4c5b-b112-36a304b66dad
, следует использовать domain_hint=consumers. Или используйте domain_hint=organizations.
code_challenge рекомендованный/обязательный Используется, чтобы защитить разрешения кода авторизации с помощью ключа проверки для обмена кодом (PKCE). Является обязательным, если указан параметр code_challenge_method. Дополнительные сведения см. в описании PKCE RFC. Это рекомендуется для всех типов приложений — как общедоступных, так и для конфиденциальных клиентов, и требуется платформой Microsoft Identity для одностраничных приложений, использующих поток кода авторизации.
code_challenge_method рекомендованный/обязательный Метод, используемый для кодирования code_verifier
в параметре code_challenge. Это должно быть S256 , но спецификация позволяет использовать, plain Если по какой бы причине клиент не поддерживает SHA256.

Если этот параметр не указан, для code_challenge принимается формат открытого текста, если задано значение code_challenge. Платформа Microsoft Identity поддерживает plain и, и S256 . Дополнительные сведения см. в описании PKCE RFC. Это необходимо для одностраничных приложений, использующих поток кода авторизации.

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

После того как пользователь пройдет проверку подлинности и предоставит согласие, платформа Microsoft Identity возвратит ответ на ваше приложение в указанном redirect_uri виде с помощью метода, указанного в response_mode параметре.

Успешный ответ

Успешный ответ с использованием метода response_mode=query выглядит следующим образом:

GET http://localhost?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
Параметр Описание
code Запрашиваемый приложением код авторизации. Приложение может использовать код авторизации для запроса маркера доступа для целевого ресурса. Срок действия кодов авторизации очень мал и обычно истекает по прошествии порядка 10 минут.
state Если запрос содержит параметр «state», в ответе должно отображаться то же значение. Приложение должно проверять идентичность значений состояния в запросе и ответе.

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

Сообщение об ошибке

Сообщения об ошибках также можно отправлять на redirect_uri , чтобы приложение обрабатывало их должным образом:

GET http://localhost?
error=access_denied
&error_description=the+user+canceled+the+authentication
Параметр Описание
error Строка кода ошибки, которую можно использовать для классификации типов возникающих ошибок и реагирования на них.
error_description Конкретное сообщение об ошибке, с помощью которого разработчик может определить причину возникновения ошибки проверки подлинности.
Коды ошибок конечной точки авторизации

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

Код ошибки Описание Действие клиента
invalid_request Ошибка протокола, например отсутствует обязательный параметр. Исправьте запрос и отправьте его повторно. Это ошибка разработки, которая обычно определяется во время первоначального тестирования.
unauthorized_client Клиентскому приложению не разрешено запрашивать код авторизации. Как правило, эта ошибка возникает, если клиентское приложение не зарегистрировано в Azure AD или не добавлено в клиент Azure AD пользователя. Приложение может отобразить пользователю запрос с инструкцией по установке приложения и его добавлению в Azure AD.
access_denied Владелец ресурса отказал в использовании Клиентское приложение может уведомить пользователя, что для продолжения работы необходимо согласие пользователя.
unsupported_response_type Сервер авторизации не поддерживает тип ответа в запросе. Исправьте запрос и отправьте его повторно. Это ошибка разработки, которая обычно определяется во время первоначального тестирования. При отображении в гибридном потокесигнализирует, что необходимо включить параметр неявного предоставления маркера идентификации для регистрации клиентского приложения.
server_error Сервер обнаружил непредвиденную ошибку. Повторите запрос. Эти ошибки могут возникать в связи с временными условиями. Из клиентского приложения может поступить сообщение о том, что его ответ задерживается из-за временной ошибки.
temporarily_unavailable Сервер временно занят и не может обработать запрос. Повторите запрос. Из клиентского приложения может поступить сообщение о том, что его ответ задерживается из-за временного состояния.
invalid_resource Целевой ресурс недопустим, так как он не существует. Azure AD не удается найти ресурс, или он настроен неправильно. Это означает, что ресурс не существует или не настроен в клиенте. Приложение может отобразить пользователю запрос с инструкцией по установке приложения и его добавлению в Azure AD.
login_required Слишком много пользователей или пользователи не найдены Клиент запросил автоматическую аутентификацию (prompt=none), но одного пользователя не удалось найти. Это может означать, что в сеансе активно несколько пользователей или пользователи отсутствуют. При этом учитывается выбранный клиент (например, если активны две учетные записи Azure AD и одна учетная запись Майкрософт и выбран параметр consumers, то автоматическая проверка подлинности будет работать).
interaction_required Для запроса требуется взаимодействие с пользователем. Требуется дополнительный шаг аутентификации или предоставление согласия. Повторите запрос без prompt=none.

Также запросите маркер идентификатора (гибридный поток)

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

Гибридный поток аналогичен потоку кода авторизации, описанному ранее, но с тремя дополнениями, необходимыми для запроса маркера идентификации: новые области, новый response_type и новый nonce параметр запроса.

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth3/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code%20id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=fragment
&scope=openid%20offline_access%20https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
&state=12345
&nonce=abcde
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Обновленный параметр Обязательный или необязательный Описание
response_type Обязательно Добавление id_token указывает серверу, что приложение должно иметь маркер идентификации в ответе от /authorize конечной точки.
scope Обязательно Для токенов ID необходимо обновить, чтобы включить области токенов ИДЕНТИФИКАТОРов openid , и при необходимости profile и email .
nonce Обязательно Значение, включаемое в создаваемый приложением запрос, которое будет использоваться как утверждение в получаемом значении id_token. Приложение может проверять это значение, чтобы устранить атаки с воспроизведением маркеров. Значение обычно представляет собой случайным образом полученную уникальную строку, которую можно использовать для идентификации источника запроса.
response_mode Рекомендуемая Определяет метод, который следует использовать для отправки созданного маркера запрашивающему приложению. По умолчанию принимает значение query только для кода авторизации, но fragment Если запрос содержит id_token response_type . Однако рекомендуется использовать приложения form_post , особенно при использовании в http:/localhost качестве URI перенаправления.

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

Успешный ответ

Успешный ответ с использованием метода response_mode=fragment выглядит следующим образом:

GET https://login.microsoftonline.com/common/oauth3/nativeclient#
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&id_token=eYj...
&state=12345
Параметр Описание
code Запрашиваемый приложением код авторизации. Приложение может использовать код авторизации для запроса маркера доступа для целевого ресурса. Коды авторизации имеют небольшой срок существования, обычно истекает через 10 минут.
id_token Маркер идентификации для пользователя, выданного через неявное предоставление. Содержит специальное c_hash утверждение, которое является хэш-кодом в том code же запросе.
state Если в запрос включен этот параметр состояния, идентичное значение должно содержаться и в ответе на этот запрос. Приложение должно проверять идентичность значений состояния в запросе и ответе.

Запрос маркера доступа

После получения кода авторизации и разрешения от пользователя вы можете применить code для получения access_token к требуемому ресурсу. Для этого отправьте запрос POST к конечной точке /token:

// Line breaks for legibility only

POST /{tenant}/oauth3/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for web apps.  This secret needs to be URL-Encoded.

Совет

Попытайтесь выполнить этот запрос в Postman. (Не забудьте заменить code.) .

Параметр Обязательный или необязательный Описание
tenant обязательно Значение {tenant} в пути запроса можно использовать для того, чтобы контролировать, кто может входить в приложение. Допустимые значения: common, organizations, consumers, а также идентификаторы клиента. Дополнительные сведения см. в описании протоколов.
client_id обязательно Идентификатор приложения (клиента), назначенный вашему приложению на странице регистрации приложений на портале Azure.
grant_type обязательно Должен быть authorization_code для потока кода авторизации.
scope необязательно Список областей с разделителями-пробелами. Все области должны быть из одного ресурса, а также с областями OIDC (profile, openid, email). Более подробное описание областей можно найти в разделе, посвященном разрешениям, согласию на их предоставление и областям. Это расширение Майкрософт для потока кода авторизации, предназначенное для того, чтобы разрешить приложениям объявлять ресурсы, на которые они хотят получить маркер во время активации токена.
code обязательно Код авторизации, полученный на первом участке потока.
redirect_uri обязательно Значение redirect_uri, которое использовалось для получения кода authorization_code.
client_secret обязательный для конфиденциальных веб-приложений Секрет приложения, созданный на портале регистрации для приложения. Не следует использовать секрет приложения в собственном приложении или одностраничном приложении, поскольку секреты клиента невозможно надежно сохранить на устройствах или на веб-страницах. Этот секрет требуется для веб-приложений и веб-API с возможностью безопасного хранения секрета клиента на сервере. Как и все описанные здесь параметры, секрет клиента должен быть закодирован в виде URL-адреса перед отправкой, что обычно выполняется с помощью пакета SDK. Дополнительные сведения о кодировке URI см. в разделе Спецификация универсального синтаксиса URI.
code_verifier рекомендуется Это тот же параметр code_verifier, который использовался для получения кода авторизации (authorization_code). Является обязательным, если в запросе на код авторизации использовался PKCE. Дополнительные сведения см. в описании PKCE RFC.

Успешный ответ

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

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
Параметр Описание
access_token Запрашиваемый маркер доступа. Приложение может использовать этот маркер для аутентификации в защищенном ресурсе, таком как веб-API.
token_type Указывает значение типа маркера. Единственный тип, поддерживаемый Azure AD, — носитель
expires_in Срок действия маркера доступа (в секундах).
scope Области, для которых действителен маркер доступа. Необязательно. Этот параметр не является стандартным, и если он опущен, маркер будет использоваться для областей, запрошенных на начальном участке последовательности.
refresh_token Маркер обновления OAuth 2.0. Приложение может использовать этот маркер для получения дополнительных маркеров доступа после истечения срока действия текущего маркера доступа. Токены обновления действуют в течение долгого времени. Их можно использовать для длительного сохранения доступа к ресурсам. См. дополнительные сведения об обновлении маркеров доступа.
Примечание. Предоставляется, только если подан запрос на область offline_access.
id_token A JSON Web Token (JWT). Приложение может декодировать сегменты этого токена, чтобы запрашивать сведения о пользователе, выполнившем вход. Приложение может кэшировать значения и отображать их, а конфиденциальные клиенты могут использовать его для авторизации. См. дополнительные сведения о маркерах id_token: id_token reference.
Примечание. Предоставляется, только если подан запрос на область openid.

Сообщение об ошибке

Сообщения об ошибках выглядят следующим образом:

{
  "error": "invalid_scope",
  "error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 255d1aef-8c98-452f-ac51-23d051240864\r\nCorrelation ID: fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7\r\nTimestamp: 2016-01-09 02:02:12Z",
  "error_codes": [
    70011
  ],
  "timestamp": "2016-01-09 02:02:12Z",
  "trace_id": "255d1aef-8c98-452f-ac51-23d051240864",
  "correlation_id": "fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7"
}
Параметр Описание
error Строка кода ошибки, которую можно использовать для классификации типов возникающих ошибок и реагирования на них.
error_description Конкретное сообщение об ошибке, с помощью которого разработчик может определить причину возникновения ошибки проверки подлинности.
error_codes Список кодов ошибок, характерных для службы маркеров безопасности, которые могут помочь при диагностике.
timestamp Время возникновения ошибки.
trace_id Уникальный идентификатор для запроса, который может помочь при диагностике.
correlation_id Уникальный идентификатор для запроса, который может помочь при диагностике нескольких компонентов.

Коды ошибок конечных точек токенов

Код ошибки Описание Действие клиента
invalid_request Ошибка протокола, например отсутствует обязательный параметр. Исправьте регистрацию запроса или приложения и отправьте запрос повторно.
invalid_grant Недопустимый или устаревший код авторизации или средство проверки PKCE. Повторите запрос к конечной точке /authorize и убедитесь, что параметр code_verifier указан правильно.
unauthorized_client У клиента, прошедшего проверку подлинности, нет прав на использование этого типа предоставления разрешения проверки подлинности. Как правило, это происходит, если клиентское приложение не зарегистрировано в Azure AD или не добавлено в клиент Azure AD пользователя. Приложение может отобразить пользователю запрос с инструкцией по установке приложения и его добавлению в Azure AD.
invalid_client Сбой проверки подлинности клиента. Недопустимые учетные данные клиента. Чтобы устранить проблему, администратору приложения необходимо обновить учетные данные.
unsupported_grant_type Сервер авторизации не поддерживает тип предоставления авторизации. Измените тип предоставления в запросе. Ошибка этого типа должна происходить только во время разработки, и ее должны обнаружить при первоначальном тестировании.
invalid_resource Целевой ресурс недопустим, так как он не существует. Azure AD не удается найти ресурс, или он настроен неправильно. Это означает, что ресурс, если он существует, не настроен в клиенте. Приложение может отобразить пользователю запрос с инструкцией по установке приложения и его добавлению в Azure AD.
interaction_required Не является стандартным, так как спецификация OIDC вызывает только для этой /authorize конечной точки. Для запроса требуется вмешательство пользователя. К примеру, требуется дополнительный шаг проверки подлинности. Повторите /authorize запрос с теми же областями.
temporarily_unavailable Сервер временно занят и не может обработать запрос. Повторите запрос через небольшую задержку. Из клиентского приложения может поступить сообщение о том, что его ответ задерживается из-за временного состояния.
consent_required Для запроса требуется согласие пользователя. Эта ошибка не является стандартной, так как обычно она возвращается только в отношении /authorize конечной точки на каждую спецификацию OIDC. Возвращается при scope использовании параметра в потоке возврата кода, который у клиентского приложения отсутствует разрешение на запрос. Клиент должен отправить пользователю обратно в /authorize конечную точку с правильной областью, чтобы активировать согласие.
invalid_scope Приложение запросило недопустимую область. Измените значение параметра области в запросе на проверку подлинности на допустимое значение.

Примечание

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

Использование маркера доступа

Успешно получив access_token, вы можете использовать этот маркер в запросах к веб-API, включая его в заголовок Authorization.

Совет

Выполните этот запрос в Postman. (Сначала замените заголовок Authorization.) .

GET /v1.0/me/messages
Host: https://graph.microsoft.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

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

Срок действия маркеров доступа весьма ограничен, поэтому их нужно обновлять после его истечения, чтобы продолжить пользоваться запросами. Для этого можно отправить еще один запрос POST на конечную точку /token, прибегнув к refresh_token вместо code. Маркеры обновления действуют для всех разрешений, на которые ваш клиент уже получил согласия, например, маркер обновления выданный по запросу для scope=mail.read может использоваться для запроса нового маркера доступа для scope=api://contoso.com/api/UseResource.

Для маркеров обновления для веб-приложений и собственных приложений не указано время существования. Обычно у маркеров обновления относительно продолжительное время существования. Но в некоторых случаях маркер обновления оказывается устаревшим или отозванным или не имеет достаточных привилегий для требуемого действия. Ваше приложение должно ожидать и правильно обрабатывать ошибки, возвращаемые конечной точкой выдачи маркера. Однако одностраничные приложения получают маркер с временем жизни 24 часа, что требует новой проверки подлинности каждый день. Это можно сделать в окне IFRAME без вмешательства пользователя, если включены сторонние файлы cookie, но они должны выполняться в рамках фрейма верхнего уровня (полная навигация по страницам или всплывающее окно) в браузерах без сторонних файлов cookie, таких как Safari.

Несмотря на то, что маркеры обновления не отзываются, когда используются для получения новых маркеров доступа, вы должны самостоятельно удалить старый маркер обновления. В спецификации OAuth 2.0 указано следующее: «Сервер авторизации может выдать новый маркер обновления. В этом случае клиент должен удалить старый маркер обновления и заменить его новым маркером обновления. Сервер авторизации может отозвать старый маркер обновления после выпуска нового маркера обновления для клиента».

Важно!

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


// Line breaks for legibility only

POST /{tenant}/oauth3/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for web apps. This secret needs to be URL-Encoded

Совет

Попытайтесь выполнить этот запрос в Postman. (Не забудьте заменить refresh_token.) .

Параметр Type Описание
tenant обязательно Значение {tenant} в пути запроса можно использовать для того, чтобы контролировать, кто может входить в приложение. Допустимые значения: common, organizations, consumers, а также идентификаторы клиента. Дополнительные сведения см. в описании протоколов.
client_id обязательно Идентификатор приложения (клиента) , назначенный вашему приложению функцией Регистрация приложений портала Azure.
grant_type обязательно Должен быть refresh_token для этого участка потока кода авторизации.
scope обязательно Список областей с разделителями-пробелами. Области, запрашиваемые на этом участке, должны быть эквивалентны областям, запрашиваемым на исходном участке запроса кода авторизации, или являться их подмножеством. Если области, указанные в этом запросе, охватывают несколько серверов ресурсов, платформа Microsoft Identity возвратит маркер для ресурса, указанного в первой области. Более подробное описание областей можно найти в разделе, посвященном разрешениям, согласию на их предоставление и областям.
refresh_token обязательно Токен обновления, полученный на втором участке потока.
client_secret необходим для веб-приложений Секрет приложения, созданный на портале регистрации для приложения. Его не следует использовать в собственном приложении, поскольку невозможно обеспечить полную безопасность секретов клиентов при их хранении на устройствах. Этот секрет требуется для веб-приложений и веб-API с возможностью безопасного хранения секрета клиента на сервере. Этот секрет должен быть закодирован в виде URL-адреса. Дополнительные сведения см. в разделе Спецификация универсального синтаксиса URI.
Успешный ответ

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

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
Параметр Описание
access_token Запрашиваемый маркер доступа. Приложение может использовать этот маркер для аутентификации в защищенном ресурсе, таком как веб-API.
token_type Указывает значение типа маркера. Единственный тип, поддерживаемый Azure AD, — носитель
expires_in Срок действия маркера доступа (в секундах).
scope Области, для которых действителен маркер доступа.
refresh_token Новый токен обновления OAuth 2.0. Вам следует заменить старый токен обновления вновь полученным, чтобы обеспечить максимальный срок действия токенов обновления.
Примечание. Предоставляется, только если подан запрос на область offline_access.
id_token Неподписанный веб-маркер JSON (JWT). Приложение может декодировать сегменты этого токена, чтобы запрашивать сведения о пользователе, выполнившем вход. Приложение может кэшировать и отображать значения, но оно не должно полагаться на них при авторизации или в целях безопасности. См. дополнительные сведения о маркерах id_token: id_token reference.
Примечание. Предоставляется, только если подан запрос на область openid.
Сообщение об ошибке
{
  "error": "invalid_scope",
  "error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 255d1aef-8c98-452f-ac51-23d051240864\r\nCorrelation ID: fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7\r\nTimestamp: 2016-01-09 02:02:12Z",
  "error_codes": [
    70011
  ],
  "timestamp": "2016-01-09 02:02:12Z",
  "trace_id": "255d1aef-8c98-452f-ac51-23d051240864",
  "correlation_id": "fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7"
}
Параметр Описание
error Строка кода ошибки, которую можно использовать для классификации типов возникающих ошибок и реагирования на них.
error_description Конкретное сообщение об ошибке, с помощью которого разработчик может определить причину возникновения ошибки проверки подлинности.
error_codes Список кодов ошибок, характерных для службы маркеров безопасности, которые могут помочь при диагностике.
timestamp Время возникновения ошибки.
trace_id Уникальный идентификатор для запроса, который может помочь при диагностике.
correlation_id Уникальный идентификатор для запроса, который может помочь при диагностике нескольких компонентов.

Описание кодов ошибок и рекомендуемых действий в клиенте см. в разделе Коды ошибок конечных точек токенов.

Аутентификация | Creatio Academy

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

Все внешние запросы к веб-сервисам Creatio должны быть аутентифицированы.

Виды аутентификации 

Виды аутентификации, которые поддерживаются в Creatio:

Рекомендуемым способом аутентификации для интеграции с приложением является Forms-аутентификация, которая реализована с помощью веб-сервиса AuthService.svc. Cookie, полученные в ответ от веб-сервиса AuthService.svc, необходимо использовать в следующих запросах к Creatio.

Пример использования аутентификационного cookie приведен в описании сервисов работы с данными OData и DataService.

Защита от CSRF-атак 

CSRF (англ. Сross Site Request Forgery — «межсайтовая подделка запроса») — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. По умолчанию защита включена, но ее можно отключить.

Важно. Отключение защиты от CSRF-атак рекомендуется использовать только в случае применения basic-аутентификации.

Защиту от CSRF-атак можно отключить для:

  • Всех сервисов приложения.
  • Одного сервиса приложения.
  • Нескольких методов разных сервисов.

Чтобы отключить защиту от CSRF-атак для всех сервисов приложения, отключите настройку UseCsrfToken в файлах Web.Config и …\Terrasoft.WebApp\Web.Config.

Чтобы отключить защиту от CSRF-атак для одного сервиса приложения, задайте имя сервиса в настройке DisableCsrfTokenValidationForPaths файла Web.Config.

Чтобы отключить защиту от CSRF-атак для нескольких методов разных сервисов, задайте методы в настройке DisableCsrfTokenValidationForPaths файла Web.Config.

Требования аутентификации и авторизации API

Edit me

Прежде чем пользователи смогут отправлять запросы с помощью 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 также может быть связан с конкретным приложением, которое регистрируется.

Ключи APK используют строку в свойстве заголовка для авторизации запросов

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.

окно входа в систему, использующую Oauth3.0

Существует несколько разновидностей 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

API ключ SendGrid

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

Twitter

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

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

Amazon Web Services

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

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

Dropbox

Авторизация в 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].

Аутентификация и авторизация в Apache Kafka и их расширение с библиотекой BlackRock

Завтра мы продолжим разбирать опыт 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 and Proxy-Authenticate headers

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.

Authorization and Proxy-Authorization headers

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:[email protected] 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

  • 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 Manager OAuth 2.0 хранит информацию о клиентском приложении, которому пользователь разрешает доступ к атрибутам и ресурсам. Эта информация уникальна для каждого пользователя. Итак, вам нужно сохранить его как часть пользовательского объекта в пользовательском хранилище. Если у вас уже есть атрибут, вы можете использовать его при определении глобальных настроек.

Если свободный атрибут недоступен, расширьте схему пользовательского объекта, добавив новый однозначный двоичный (LDAP) или потоковый (eDirectory) атрибут с именем.Access Manager будет хранить XML-объект в этом атрибуте для каждой авторизации пользователя.

ПРИМЕЧАНИЕ: Суперадминистратор LDAP должен иметь доступ на запись к этому атрибуту пользователя, чтобы разрешить сохранение информации токена. Access Manager использует этот атрибут для отзыва токенов обновления.

Пример расширения схемы объекта пользователя в eDirectory

  1. Щелкните, чтобы>>.

  2. Укажите как nidsOAuthGrant.

  3. Щелкните.

  4. Выбрать под.

  5. Щелкните.

  6. Выбрать.

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

  8. Перейти к>>.

  9. Выберите человека под.

  10. Щелкните.

  11. Переместить nidsOAuthGrant из в.

  12. Щелкните.

Пример расширения схемы объекта пользователя в Active Directory

  1. В Windows:>>.

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

  3. Выберите, затем щелкните.

  4. Разверните, затем щелкните правой кнопкой мыши>.

  5. В диалоговом окне укажите следующее:

    • : 1.3.6.1.4.1.1466.115.121.1.5

  6. Выбрать как.

    Убедитесь, что этот флажок снят.

  7. Щелкните.

  8. Разверните, затем щелкните>.

  9. Щелкните правой кнопкой мыши, затем щелкните.

  10. Щелкните вкладку, затем щелкните.

  11. Выберите созданный вами атрибут (nidsOAuthGrant), затем щелкните.

  12. Щелкните, чтобы закрыть все окна свойств, затем добавьте атрибут в класс людей.

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

  1. Перейти к схеме служб Active Directory облегченного доступа к каталогам (AD LDS).

  2. Щелкните правой кнопкой мыши имя схемы, затем щелкните>.

  3. Выберите и щелкните.

  4. Укажите общее имя и щелкните.

  5. Укажите 4 для атрибута oMSyntax и щелкните.

  6. Укажите отображаемое имя LDAP и щелкните. Это значение должно совпадать с общим именем.

  7. Укажите True для атрибута isSingleValued и щелкните.

  8. Укажите 2.5.5.10 для атрибута attributeSyntax и щелкните.

  9. Укажите 1.2.840.113556.1.9000.50.1 для атрибута attributeID и щелкните.

  10. Щелкните.

  11. Перейдите к классу cn = Person, дважды щелкните, чтобы изменить атрибут.

  12. Выберите атрибут mayContain и щелкните.

  13. Укажите имя атрибута (общее имя) и щелкните>.

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

  15. Щелкните правой кнопкой мыши схему>.

    ПРИМЕЧАНИЕ. При создании нового пользователя для атрибута msDS-UserAccountDisabled по умолчанию установлено значение true. Измените значение на false.

Определение глобальных настроек

Глобальные параметры позволяют указать параметры OAuth и OpenID Connect по умолчанию для сервера авторизации, такие как URL-адрес эмитента, типы токенов, гранты и т. Д.

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

  2. На этой странице вы можете настроить и просмотреть следующие детали:

    Эмитент

    Укажите имя сервера авторизации.Это имя будет частью идентификатора токена.

    Разрешение на авторизацию Атрибут LDAP

    Укажите двоичный атрибут или атрибут потока (для eDirectory), который существует в пользовательском хранилище. Например, nidsOAuthGrant.

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

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

    ПРИМЕЧАНИЕ: Это обязательное поле. Этот атрибут хранит информацию о токене обновления. Эта информация может быть использована позже для токена JWT для проверки отзыва. Убедитесь, что ни одно другое приложение не использует этот атрибут.

    Домены CORS

    Выберите любой из следующих вариантов в зависимости от требования:

    • Если вы хотите запретить доступ для запросов со всех доменов, кроме домена ресурса.Ресурсы, упомянутые здесь, — это такие ресурсы, как Javascript в клиентском приложении.

    • Если вы хотите разрешить доступ для запросов из любых доменов.

    • Если вы хотите разрешить доступ для запросов только из выбранных доменов. Укажите домен с номером порта. Не указывайте порт, если вы используете порт 80 или 443.

    Примеры: beem: //www.test.com: порт, fb: //app.local.url: порт, https://namapp.com:port

    ПРИМЕЧАНИЕ. Access Manager предоставляет маркер доступа, даже если запрос не включает указанный домен.Но токен проверяется на следующих конечных точках:

    • UserInfo

    • TokenInfo

    • Отзыв

    • Token Introspect

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

    Заголовок Access-Control-Allow-Credentials

    Выберите этот параметр, чтобы разрешить фильтру CORS Access Manager отправлять заголовок Access-Control-Allow-Credentials с ответом.

    Тип гранта

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

    Дополнительные сведения о типах грантов см. В разделе «Грант авторизации OAuth».

    Типы токенов

    Выберите типы токенов, которые будет поддерживать сервер авторизации.

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

    • Токен доступа: Включает конкретные объемы и продолжительность предоставленного доступа.

    • Токен обновления: Используется для получения нового токена доступа, когда токен доступа становится недействительным или истекает.

    Отзыв токена

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

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

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

    ПРИМЕЧАНИЕ: Отзыв двоичных токенов не поддерживается.

    Выполнить проверку отзыва после

    (Access Manager 4.5 с пакетом обновления 2 и более поздние версии)

    Укажите продолжительность в секундах. По истечении этого времени Access Manager проверяет, отозван ли токен.

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

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

    Время ожидания кода авторизации

    Укажите продолжительность в минутах после того, как код авторизации станет недействительным.

    Токен доступа и тайм-аут идентификатора

    Укажите продолжительность в минутах после того, как токен доступа и токен ID станут недействительными.

    Тайм-аут токена обновления

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

    Свидетельство о подписании

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

    Невозможно добавить внешний сертификат в OAuth, потому что в Access Manager Appliance нет возможности назначать сертификаты хранилищу ключей. Можно использовать только сертификаты, доступные в nam-keystore.

    Контракты на аутентификацию учетных данных владельца ресурса

    Выберите поддерживаемые контракты из списка и переместите их в Поле.

    Этот параметр позволяет администратору настроить поток владельца ресурса для выполнения определенного контракта аутентификации. Он поддерживает только контракты на основе имени / пароля.

    Порядок заключения договора аутентификации должен быть следующим:

    1. Значения acr_values ​​в параметре запроса.

    2. Опция глобальной настройки OAuth.

    3. Контракт по умолчанию.

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

    Чтобы выбрать настраиваемый контракт для проверки подлинности, настраиваемый класс проверки подлинности должен переопределить метод cbAuthenticate. Для получения дополнительной информации см. Руководство по SDK NetIQ Access Manager 4.5.

  3. Щелкните.

Настройка сервера ресурсов

Access Manager позволяет вам определять настройки для шифрования токена доступа, добавляя сервер ресурсов в Identity Server.Вы можете добавить сервер ресурсов в зависимости от требований шифрования каждого сервера ресурсов OAuth. Сервер ресурсов может проверять и принимать токены, отправленные клиентскими приложениями, а затем предоставлять доступ к ресурсам.

Access Manager также позволяет изменять и удалять настроенные серверы ресурсов. Настройка сервера ресурсов состоит из следующих действий:

Добавление сервера ресурсов

Добавление сервера ресурсов в Access Manager (Identity Server) требуется только для указания любого из следующих механизмов шифрования токенов доступа для конкретного сервера ресурсов OAuth:

Токены доступа и идентификатора содержат области (утверждения пользователя) в форме атрибутов пользователя или разрешений для клиентов на использование защищенного ресурса.Вы можете настроить области для каждого сервера ресурсов.

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

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

Администратор настраивает RS1 для использования ключа Access Manager для шифрования токена доступа и настраивает RS2 для использования ключа сервера ресурсов. Кроме того, администратор определяет область действия Scope1 для сервера ресурсов RS1 и область действия Scope2 для сервера ресурсов RS1.

RS1

Зашифровать с помощью ключа Access Manager

Объем1

RS2

Зашифровать с использованием ключа сервера ресурсов

Объем2

Теперь, когда клиентское приложение отправляет запрос токена с параметром scope как Scope1 и параметром resourceServer как RS2, Identity Server добавляет Scope1 к токену с механизмом шифрования, указанным в RS2.

Параметр

Значение

Область действия добавлена ​​к токену

Механизм шифрования токена

ресурсов Сервер

RS2

Объем1

Зашифровано с использованием сервера ресурсов, ключ RS2

область применения

Объем1

Выполните следующие шаги, чтобы добавить сервер ресурсов в Identity Server:

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

  2. Щелкните.

  3. Укажите имя для сервера ресурсов.

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

    • Не шифровать: Выберите этот вариант, если вам не требуется шифрование токена доступа.

    • Зашифровать с помощью ключа диспетчера доступа: Это вариант по умолчанию.Если вы выберете эту опцию, токен будет зашифрован и подтвержден с помощью ключей Access Manager.

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

  5. (условно) Если вы выбрали, укажите значения для следующих полей:

    Для понимания использования следующих полей см. Шифрование токена с помощью ключа сервера ресурсов.

  6. Щелкните.

    Продолжите определение областей для сервера ресурсов.

Ограничение количества запросов

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

Откройте /opt/novell/nam/idp/conf/tomcat.conf. Добавьте следующий параметр:

JAVA_OPTS = «$ {JAVA_OPTS} -Dcom.novell.oauth.threshold.maxrequestsallowed = <количество запросов>»

Например, JAVA_OPTS = «$ {JAVA_OPTS} -Dcom.novell.oauth.threshold.maxrequestsallowed = 10 «. Он не допускает более 10 запросов в секунду.

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

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

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

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

ПРИМЕЧАНИЕ:

  • В области действия можно получить атрибуты на основе LDAP.

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

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

Выполните следующие шаги, чтобы определить области и разрешения:

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

  2. Выберите имя сервера ресурсов, для которого вы хотите определить новую область.

  3. Щелкните.

  4. Укажите следующие реквизиты:

    Имя

    Укажите имя для области.

    Описание

    Укажите описание области.На странице согласия отображается это описание.

    Включить претензии типа

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

    • Атрибуты пользователя: Выберите этот вариант, если вам необходимо использовать любой из пользовательских атрибутов LDAP в области.

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

      ПРИМЕЧАНИЕ. Виртуальные атрибуты могут использоваться для атрибутов на основе LDAP и для постоянных значений.

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

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

    Требовать разрешения пользователя

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

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

    ПРИМЕЧАНИЕ: Если вы отмените выбор этого параметра, область не будет указана в поле scopes_supported конечной точки метаданных.Кроме того, поле Claims_supported конечной точки метаданных не будет отображать утверждения для этой области, даже если настроен атрибут пользователя или настраиваемые утверждения / разрешения.

    Разрешить изменение при согласии

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

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

  5. Щелкните.

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

Настройка требований или разрешений пользователей в области действия

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

  1. (при условии) Если вы выбрали создание области действия, выполните следующие действия:

    1. Выберите требуемый набор атрибутов из профиля LDAP или создайте новый набор атрибутов.

      Здесь перечислены атрибуты пользователя в наборе атрибутов.

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

    2. Чтобы добавить область пользовательского атрибута к токену доступа, выберите необходимые атрибуты, которые должны быть добавлены к токену доступа, затем щелкните>.

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

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

      ПРИМЕЧАНИЕ: Размер токена зависит от значения атрибута, включенного в токен. Следовательно, рекомендуется включать в токен только обязательный атрибут.

      Если вам необходимо удалить определенный атрибут из токена идентификатора, выберите атрибут и щелкните>.

      ПРИМЕЧАНИЕ: Атрибуты не добавляются и не удаляются из уже выданного маркера идентификатора.

    4. (при условии) Если требуется, чтобы выбранные атрибуты были доступны как в маркере идентификатора, так и в маркере доступа, то после выбора атрибутов щелкните>.

      Если вам необходимо удалить определенные атрибуты как из токена доступа, так и из токена идентификатора, то после выбора этих атрибутов щелкните>.

  2. (при условии) Если вы использовали, выполните следующее:

    1. Щелкните, чтобы создать новое настраиваемое утверждение.

    2. В укажите разрешение, которое клиент получает после использования токена доступа.

    3. Вы можете выбрать требуемое утверждение, которое должно быть добавлено к токену доступа, затем выберите>.

      Чтобы удалить конкретное утверждение из маркера доступа, щелкните>.

      ПРИМЕЧАНИЕ. Утверждения не добавляются и не удаляются из уже выданного токена доступа.Вы можете просмотреть новинки в наборе претензий. Имя ключа — это утверждения, а значение — список строк.

    4. Вы можете выбрать требуемое утверждение, которое следует добавить к токену идентификатора, а затем выбрать>.

      Чтобы удалить конкретное утверждение из идентификатора токена, щелкните>.

      ПРИМЕЧАНИЕ. Утверждения не добавляются и не удаляются из уже выданного идентификатора токена. Вы можете просмотреть новинки в наборе претензий. Имя ключа — это утверждения, а значение — список строк.

    5. (при условии) Если вам необходимо выбрать утверждения, которые должны быть доступны как для токена доступа, так и для токена идентификатора, то после выбора утверждений щелкните>.

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

      ПРИМЕЧАНИЕ: Заявки не добавляются и не удаляются из уже выпущенных токенов. Эти утверждения отображаются в виде списка строк под атрибутом требований в токенах доступа и идентификатора.

Изменение областей сервера ресурсов

Вы можете изменить объем зарегистрированного сервера ресурсов. Access Manager позволяет удалить сервер ресурсов или удалить область сервера ресурсов.

Чтобы изменить объемы сервера ресурсов, выполните следующие действия:

  1. Щелкните>>>>. На этой странице перечислены все зарегистрированные серверы ресурсов.

  2. Щелкните сервер ресурсов> область, которую нужно изменить.

  3. На странице «Изменить область действия» измените необходимые сведения. Дополнительные сведения о полях на этой странице см. В разделе Определение областей для сервера ресурсов.

  4. Щелкните.

Изменение утверждений и атрибутов

Вы можете изменить или удалить определенное утверждение. Вы также можете обновить атрибуты, связанные с областью. Если вы выбрали при создании области, Identity Server извлекает необходимую информацию из конечной точки userinfo.Вы можете изменить связанные атрибуты LDAP.

Чтобы удалить настраиваемое утверждение или разрешение, вы можете выбрать необходимое разрешение и щелкнуть.

Дополнительные сведения об атрибутах и ​​утверждениях пользователей см. В разделе «Определение областей для сервера ресурсов».

Регистрация клиентских приложений OAuth

Клиентское приложение, которое отправляет запросы API в Access Manager, должно быть зарегистрировано на сервере идентификации Access Manager. В рамках регистрации укажите имя клиента, перенаправления (URI) и любые другие данные поставщика, требуемые API.Вы можете зарегистрировать клиентское приложение, используя вызовы API, Консоль администрирования или страницу пользовательского портала Identity Server.

Необходимые условия для управления клиентскими приложениями:

  • Пользовательский портал: определите любую из следующих ролей в политике OAuth для пользователя:

    • : Позволяет пользователю просматривать и изменять сведения о регистрации клиента приложений, которые пользователь зарегистрировал на портале.

    • : Позволяет пользователю просматривать и изменять сведения о регистрации клиентов всех клиентских приложений, зарегистрированных в Access Manager.

    Пользователь (разработчик приложения) должен войти в систему Identity Server для регистрации клиентского приложения.

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

  • API-вызовы: определите роль в политике OAuth для пользователя.

  • Консоль администрирования: пользователь должен запросить у администратора Access Manager регистрацию клиентского приложения с помощью Консоли администрирования.

Регистрация клиентских приложений OAuth

Выполните следующие шаги для регистрации клиентского приложения:

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

  2. Укажите следующие реквизиты:

    Имя клиента

    Укажите имя клиентского приложения.

    Тип клиента

    Выберите, является ли это клиентским веб-приложением или настольным клиентским приложением.

    Если выбрать, отображается.

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

    Например, пользователь обращается к клиенту A, используя учетные данные, и проходит аутентификацию. Клиент A получает токен обновления и токен доступа. Теперь пользователь обращается к клиенту B сразу или через несколько дней.Если этот параметр включен для клиента B, клиент использует постоянный файл cookie для получения токена и аутентификации пользователя. Следовательно, клиент B будет автоматически аутентифицирован.

    Если не выбрано для конфигурации клиента B, пользователь должен предоставить учетные данные для получения токена обновления и токена доступа.

    ПРИМЕЧАНИЕ: Когда клиентское приложение использует поток кода авторизации, запрос должен содержать параметр revocation_id вместе с параметром clientID. Значение revocation_id может быть идентификатором устройства.

    Если параметр revocation_id не включен в запрос, пользователь не может использовать постоянный файл cookie для аутентификации от клиента B.

    URI перенаправления

    Укажите URI в зависимости от типа клиента.

    Укажите URI, которые Identity Server использует для отправки кода авторизации и неявных запросов.

    Для веб-приложений укажите тип клиента в следующем формате: https://client.example.org/callback

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

    https: // www.namnetiq.in/

    x-com.netiq.sample: //www.namnetiq.in/

    urn: ietf: wg: oauth: 2.0: oob (поддерживается только для потока кода авторизации).

    Требуемые гранты

    Выберите типы грантов, необходимые для этого клиентского приложения. Доступные типы грантов включают:

    Типы токенов

    Выберите тип токена, который сервер авторизации вернет этому клиентскому приложению.Доступны следующие токены:

    • Код

    • Идентификационный токен

    • Токен обновления

    • Маркер доступа

    Токен обновления

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

  3. (при условии) Если вы выбрали «под», щелкните и настройте следующие параметры:

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

    • Алгоритм ответа с подписью идентификатора токена: Это обязательное поле для выдачи токена идентификатора клиентскому приложению. Если вам требуется, чтобы Identity Server подписал токен идентификатора с помощью алгоритма JWS, выберите соответствующий алгоритм подписи. Алгоритм подписи зависит от сертификата, указанного в разделе «Параметры сертификата» на странице «Глобальные параметры».

      Например, если на странице отображается RS256, выберите это поле.

      ПРИМЕЧАНИЕ: Если вы выберете эту опцию, идентификатор будет отправлен как беззнаковый маркер. Убедитесь, что вы выбрали этот вариант, только если вы можете доверять целостности неподписанного токена идентификатора.

    • Алгоритм зашифрованного ответа идентификатора токена: Укажите алгоритм JWE, который требуется для шифрования ключа зашифрованного содержимого в токене идентификатора.

      ПРИМЕЧАНИЕ: Убедитесь, что вы указали алгоритм, который определен в указанном, чтобы клиентское приложение могло использовать закрытый ключ для расшифровки токена.

    • Идентификационный токен зашифрованный ответ Enc: Это поле заполняется автоматически в соответствии с алгоритмом, указанным в.

      Это алгоритм кодирования JWE, который требуется для шифрования содержимого токена идентификатора.

  4. Щелкните.

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

    • Тайм-аут кода авторизации: Укажите срок, по истечении которого срок действия кода авторизации истечет.

    • Тайм-аут токена доступа и идентификатора: Укажите срок, по истечении которого срок действия доступа и токена идентификатора истечет.

    • Тайм-аут токена обновления: Укажите продолжительность, по истечении которой срок действия токена обновления истечет.

    • Формат токена доступа и обновления: Рекомендуется выбрать токен JWT, но вы можете выбрать любой из следующих вариантов в зависимости от требований клиентского приложения:

      ПРИМЕЧАНИЕ: Этот параметр доступен в Access Manager 4.5 Service Pack 1 и новее.

      • По умолчанию: Выберите этот параметр, чтобы использовать формат токена как двоичный или JWT. Формат будет установлен на основе значения, которое вы установили в свойстве Identity Server. Значения описаны в следующей таблице:

        Установить на

        двоичный

        Установить на

        JWT

        Не указано

        JWT

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

      • двоичный: Выберите этот вариант, если клиентскому приложению требуются токены в двоичном формате. При выборе этого параметра формат токена всегда будет двоичным независимо от значения, установленного в свойстве Identity Server.

        Двоичные токены всегда шифруются с помощью ключей Access Manager. Для проверки токена сервер ресурсов использует диспетчер доступа и конечную точку.

        Если токены в двоичном формате, следующие функции недоступны:

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

      • JWT: Это рекомендуемый формат. Выберите этот вариант, если требуется, чтобы клиентское приложение использовало токены в формате JWT. Когда вы выбираете эту опцию, формат токена всегда будет JWT, независимо от значения, установленного в свойстве Identity Server.

  5. Щелкните.

    Укажите следующие реквизиты:

    URL логотипа клиента

    Укажите URL-адрес логотипа, который вы хотите включить на страницу согласия.

    Политика конфиденциальности URL

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

    URL-адрес условий использования

    Укажите URL-адрес условий обслуживания.

    Контакты

    Укажите адреса электронной почты людей, связанных с этим клиентским приложением.

  6. Щелкните и добавьте. Настроенные здесь домены могут получить доступ к ограниченным ресурсам, доступным в клиентском приложении. Это необязательный шаг. Не указывайте порт, если вы используете порт 80 или 443.

    Примеры: beem: //www.test.com: порт, fb: //app.local.url: порт, https://namapp.com:port

  7. Щелкните.

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

Изменение зарегистрированных клиентских приложений

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

  1. Щелкните>>>>.На странице перечислены все зарегистрированные клиентские приложения со следующей информацией:

    Клиентское приложение

    Название зарегистрированной заявки

    Тип приложения

    Тип приложения: Интернет или собственное / настольное

    Создано

    Имя пользователя лица, зарегистрировавшего клиентское приложение.

    Действия

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

    • Просмотр сведений о зарегистрированном клиентском приложении

    • Удалить зарегистрированное клиентское приложение

    • Изменить данные зарегистрированного клиентского приложения.

  2. Щелкните значок редактирования под.Откроется страница конфигурации клиента. При необходимости измените детали. Дополнительные сведения о полях см. В разделе Регистрация клиентских приложений OAuth.

  3. Щелкните.

с использованием OAuth 2.0 | Slack

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

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

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

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

Самый простой способ включить рабочие области для установки вашего приложения — нажать кнопку Добавить в Slack .

Войти с помощью Slack — лучший способ регистрировать отдельных участников в вашем приложении.

Поток OAuth

Slack использует поток предоставления кода авторизации OAuth 2.0 для выдачи токенов доступа от имени пользователей.

Поток OAuth — ваш ключ к разблокировке токенов доступа. Нет пути для программного создания (или извлечения) токенов доступа к приложениям без ввода данных пользователем.

Шаг 1. Отправка пользователей для авторизации и / или установки

Ваше веб-приложение или мобильное приложение должно перенаправлять пользователей на следующий URL:

https: // слабина.com / oauth / авторизовать

В качестве параметров GET необходимо передать следующие значения:

  • client_id — выдается при создании приложения (обязательно)
  • scope — разрешения на запрос (см. Ниже) (обязательно)
  • redirect_uri — URL для обратного перенаправления (см. Ниже) (необязательно)
  • состояние — уникальная строка, которая будет возвращена после завершения (необязательно)
  • team — ID группы Slack рабочей области, которую необходимо ограничить (необязательно)

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

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

Примечание. URL-адреса перенаправления и URI могут , но не , содержать якорь ( # ).

Оптимизируйте этот шаг дополнительно с помощью URL-адреса прямой установки.

Как ведет себя команда
параметр

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

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

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

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

Шаг 2. Пользователи перенаправляются на ваш сервер с кодом подтверждения

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

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

Шаг 3. Замена проверочного кода на токен доступа

Если все в порядке, замените код авторизации на токен доступа с помощью метода API oauth.access (документация по методам).

https://slack.com/api/oauth.access

  • client_id — выдается при создании приложения (обязательно)
  • client_secret — выдается при создании приложения (обязательно)
  • код — код временной авторизации (обязательно)
  • redirect_uri — должен соответствовать первоначально представленному URI (если он был отправлен)

Вы получите ответ JSON, содержащий access_token (среди прочего):

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

Токены доступа для всех приложений также известны как токены на предъявителя.См. В разделе «Типы токенов» обзор всех типов токенов, используемых на платформе Slack.

Затем этот токен можно использовать для вызова методов API от имени пользователя. Токен будет продолжать работать до тех пор, пока устанавливающий пользователь не отзовет токен и / или не удалит ваше приложение.

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

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

Это возможность вернуть пользователей к работе, перенаправив их на глубокие ссылки в Slack.

Токены доступа пользователей ботов

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

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

Вот более подробный пример ответа JSON, включая токен доступа пользователя бота:

  {
    "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"
    }
}
  

В этом ответе узел bot содержит два поля, относящихся к вашему пользователю-боту: bot_user_id и bot_access_token . Токены доступа ботов всегда начинаются с xoxb .

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

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

Шаг 3а — Запросы отклонены

Если пользователь отклоняет ваш запрос, Slack перенаправляет обратно на ваш redirect_uri с параметром error .

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

Приложения должны обрабатывать это состояние соответствующим образом.

Хранение токенов и учетных данных

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

Ограничьте доступ к веб-API только IP-адресами, которым вы доверяете, добавив определенные IP-адреса в белый список.

Использование токенов доступа

Токены, предоставленные вашему приложению, можно использовать в запросах к веб-API.

На платформе Slack используется множество различных типов токенов. См. Наш указатель типов токенов для экскурсии.

Наилучший способ передачи ваших токенов доступа, также известных как токены носителя, — это представление их в HTTP-заголовке запроса Authorization :

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

Этот подход требуется при использовании application / json с методом записи.

В качестве альтернативы вы можете отправить токен как строку запроса или атрибут тела POST application / x-www-form-urlencoded разновидность:

В строке запроса:

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

или тело сообщения POST:

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

URI перенаправления

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

  ОБРАТНЫЙ ЗВОНОК: 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.орг
  

Обработка множественных авторизаций

Ваше приложение может отправлять пользователя через поток OAuth несколько раз.

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

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

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

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

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

Дополнительные объемы

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

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

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

Когда вы делаете запросы к веб-API, HTTP-заголовок X-OAuth-Scopes будет возвращаться с каждым ответом, указывающим, какие области у вызывающего токена в настоящее время есть:

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

Проверка личности без установки

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

Отзыв токенов и удаление приложений

Для приложений рабочей области используйте apps.uninstall , чтобы полностью удалить приложение, отозвав все токены.

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

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

Отзыв токенов и запрос пользователя на повторную аутентификацию — лучший способ начать с и постепенно добавлять к токену более ограниченные области OAuth.

Приложение: создание классического Slack-приложения

Если вам все еще нужно создать классическое приложение Slack, используйте rtm.подключите метод или по любой другой причине нажмите здесь:

Затем вы можете продолжить распространение через первую версию OAuth 2.0, описанную на этой странице.

Запросы на авторизацию | Postman Learning Center

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

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

Содержание

Указание реквизитов авторизации

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

Эти типы аутентификации можно использовать с Newman и мониторами, а также в приложении Postman.

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

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

Наведите указатель мыши на заголовок, чтобы увидеть, где он был добавлен. Чтобы изменить заголовок аутентификации, вернитесь на вкладку Авторизация и обновите конфигурацию.

Вы не можете переопределить заголовки, добавленные выбором Authorization непосредственно на вкладке Headers . Если вам нужны заголовки аутентификации, отличные от автоматически созданных Postman, измените настройки в Авторизация или удалите настройки аутентификации и добавьте заголовки вручную.

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

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

Наследование аутентификации

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

Выберите коллекцию или папку в Коллекции слева от Почтальона.Обзор коллекции или папки откроется во вкладке для редактирования. Выберите вкладку Авторизация .

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

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

Нет аутентификации

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

Ключ API

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

Почтальон добавит соответствующую информацию в ваш запрос Заголовки или строку запроса URL.

Жетон на предъявителя

Токены на предъявителя позволяют запросам аутентифицироваться с использованием ключа доступа, такого как веб-токен JSON (JWT). Токен — это текстовая строка, включенная в заголовок запроса.На вкладке «Запрос Авторизация » выберите Bearer Token из раскрывающегося списка Тип . В поле Token введите значение ключа API или для дополнительной безопасности сохраните его в переменной и укажите на нее имя.

Почтальон добавит значение токена к тексту «Bearer» в требуемом формате в заголовок авторизации запроса следующим образом:

Если требуется настраиваемый префикс, используйте ключ API с ключом Авторизация .

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

Базовая аутентификация включает отправку проверенного имени пользователя и пароля с вашим запросом. На вкладке запроса Авторизация выберите Базовая аутентификация из раскрывающегося списка Тип .

Введите данные для входа в API в полях Имя пользователя и Пароль — для дополнительной безопасности вы можете сохранить их в переменных.

В запросе Headers вы увидите, что заголовок авторизации будет передавать API строку в кодировке Base64, представляющую значения вашего имени пользователя и пароля, добавленную к тексту «Basic» следующим образом:

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

Авторизация дайджеста

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

На вкладке Авторизация для запроса выберите Digest Auth из раскрывающегося списка Тип . Почтальон представит поля для обоих этапов запроса аутентификации, однако он будет автоматически заполнять поля для второго запроса, используя данные, возвращенные сервером по первому запросу.Чтобы позволить Postman автоматизировать поток, введите Username и Password значения (или переменные), и они будут отправлены со вторым запросом.

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

Дополнительные поля необязательны, и Postman попытается заполнить их автоматически при выполнении вашего запроса.

  • Область: Строка, указанная сервером в заголовке ответа WWW-Authenticate .
  • Nonce: Уникальная строка, указанная сервером в заголовке ответа WWW-Authenticate .
  • Алгоритм: Строка, указывающая пару алгоритмов, используемых для создания дайджеста и контрольной суммы. Почтальон поддерживает алгоритмы MD5, и SHA .
  • qop: Качество защиты, примененной к сообщению.Значение должно быть одной из альтернатив, указанных сервером в заголовке ответа WWW-Authenticate .
  • Nonce Count: Шестнадцатеричный счетчик количества запросов (включая текущий запрос), которые клиент отправил со значением nonce в этом запросе.
  • Client Nonce: Строковое значение в непрозрачных кавычках, предоставляемое клиентом, используемое как клиентом, так и сервером, чтобы избежать выбранных атак с открытым текстом, обеспечить взаимную аутентификацию и обеспечить некоторую защиту целостности сообщения.
  • Opaque: Строка данных, указанная сервером в заголовке ответа WWW-Authenticate , которая должна использоваться без изменений с URI в том же пространстве защиты.

OAuth 1.0

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

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

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

Postman поддерживает OAuth Core 1.0 Редакция A.

На вкладке Авторизация для запроса выберите OAuth 1.0 из раскрывающегося списка Тип .

Выберите метод подписи из раскрывающегося списка — это определит, какие параметры вы должны включить в свой запрос. Почтальон поддерживает HMAC-SHA1 , HMAC-SHA256 , HMAC-SHA512 , RSA-SHA1 , RSA-SHA256 , RSA-SHA512 и PLAINTEXT .

  • Если вашему серверу требуется подпись HMAC или PLAINTEXT , Почтальон предоставит поля Consumer Key , Consumer Secret , Access Token и Token Secret .
  • Если вы используете подпись RSA , Почтальон представит входные данные Consumer Key , Access Token и Private Key .

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

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

Если вы отправляете данные OAuth 1.0 в заголовках, вы увидите заголовок авторизации, отправляющий ваши значения ключа и секрета, добавленные к строке «OAuth» вместе с дополнительными необходимыми деталями, разделенными запятыми.

Почтальон добавит OAuth 1.0 в запрос Заголовки , когда вы заполнили все обязательные поля в настройке Авторизация .

Если вы отправляете данные OAuth 1.0 в теле и URL-адресе, вы найдете данные, добавленные в запрос Body или Parameters в зависимости от метода запроса.

Если метод запроса — POST или PUT , и если тип тела запроса — x-www-form-urlencoded , Postman добавит параметры авторизации в тело запроса.В противном случае, например, в запросе GET ваш ключ и секретные данные будут переданы в параметрах запроса URL.

Значения параметра аутентификации OAuth 1.0 следующие:

  • Метод подписи : метод, который ваш API использует для аутентификации запросов.
  • Consumer Key: Значение, используемое для идентификации потребителя с поставщиком услуг.
  • Секрет потребителя: Значение, используемое потребителем для установления владения ключом. Для методов подписи HMAC и PLAINTEXT .
  • Маркер доступа: Значение, представляющее разрешение потребителя на доступ к данным пользователя.
  • Секрет токена: Значение, используемое потребителем для установления права собственности на данный токен. Для методов подписи HMAC и PLAINTEXT .
  • Закрытый ключ: Закрытый ключ для генерации подписи аутентификации. Для методов подписи RSA .
  • Расширенные параметры:

    • URL-адрес обратного вызова: поставщик услуг URL-адреса перенаправит на следующую авторизацию пользователя. Требуется, если ваш сервер использует OAuth 1.0 версии A.
    • Проверяющий: Проверочный код от поставщика услуг после аутентификации пользователя.
    • Отметка времени: Отметка времени, которую сервер использует для предотвращения атак повторного воспроизведения за пределами временного окна.
    • Одноразовый номер: Случайная строка, созданная клиентом.
    • Версия: Версия протокола аутентификации OAuth (1.0).
    • Область: Строка, указанная сервером в заголовке ответа WWW-Authenticate .
    • Включить хэш тела: Хеш для проверки целостности с телами запроса кроме application / x-www-form-urlencoded . Отключено при использовании URL обратного вызова / верификатора.

Если на вашем сервере реализован OAuth 1.0 требует этого, отметьте Добавить пустые параметры в подпись .

Вы также можете установить флажок Кодировать параметры в заголовке авторизации для вашего запроса.

OAuth 2.0

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

Пример потока OAuth 2.0 может работать следующим образом:

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

На вкладке Авторизация для запроса выберите OAuth 2.0 из раскрывающегося списка Тип . Укажите, хотите ли вы передавать данные аутентификации в URL-адресе запроса или в заголовках.

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

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

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

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

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

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

Код авторизации

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

Чтобы использовать тип предоставления кода авторизации, введите URL-адрес обратного вызова для вашего клиентского приложения (которое должно быть зарегистрировано у поставщика API) вместе с различными деталями, предоставляемыми службой API, включая Auth URL , Access Token URL , Идентификатор клиента и Секрет клиента .

Вы можете ввести свои данные аутентификации в веб-браузере, а не в Postman, если хотите, выбрав Авторизоваться в браузере .

Код авторизации (с PKCE)

Вы можете использовать PKCE (Proof Key for Code Exchange) с OAuth 2.0. Когда вы выбираете Код авторизации (с PKCE) , станут доступны два дополнительных поля для Code Challenge Method и Code Verifier . Вы можете выбрать использование алгоритмов SHA-256, или Plain для генерации запроса кода.Верификатор — это необязательная строка из 43–128 символов, соединяющая запрос авторизации с запросом токена.

Код авторизации (с PKCE) Тип предоставления в сочетании с Авторизация с использованием браузера рекомендуется для предотвращения атак с перехватом кода авторизации.

Неявный

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

Чтобы использовать неявный тип предоставления с вашими запросами в Postman, введите URL-адрес обратного вызова , который вы зарегистрировали у поставщика API, поставщик URL-адрес аутентификации и идентификатор клиента для зарегистрированного приложения.

Вы можете ввести свои данные аутентификации в веб-браузере, а не в Postman, если хотите, выбрав Авторизоваться в браузере .

Пароль и учетные данные

OAuth 2.0 Тип предоставления пароля включает отправку имени пользователя и пароля непосредственно от клиента и поэтому не рекомендуется, если вы имеете дело со сторонними данными.

Чтобы использовать тип предоставления пароля, введите URL-адрес маркера доступа вашего поставщика API вместе с именем пользователя и паролем .В некоторых случаях вам также потребуется предоставить идентификатор клиента и секрет.

Учетные данные клиента

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

Введите URL-адрес маркера доступа провайдера вместе с идентификатором клиента и секретом клиента для зарегистрированного приложения.

Запрос токена OAuth 2.0

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

Вкладка параметров конфигурации
  • Имя токена: Имя, которое вы хотите использовать для токена.
  • Тип гранта: Раскрывающийся список параметров. Это будет зависеть от требований поставщика услуг API.
  • URL-адрес обратного вызова: URL-адрес обратного вызова клиентского приложения, на который перенаправляется после аутентификации, и который должен быть зарегистрирован у поставщика API. Если не указан, Postman будет использовать пустой URL-адрес по умолчанию и попытается извлечь из него код или токен доступа.Если это не работает для вашего API, вы можете использовать следующий URL: https://oauth.pstmn.io/v1/browser-callback

    • Авторизация с помощью браузера: Вы можете ввести свои учетные данные в своем веб-браузере вместо всплывающего окна, которое появляется в Postman по умолчанию при использовании типа предоставления Код авторизации или Неявный . Установка этого флажка приведет к установке URL-адреса обратного вызова для возврата в Почтальон. Если вы решите авторизоваться с помощью браузера, убедитесь, что для URL обратного вызова отключены всплывающие окна, иначе это не сработает.
  • URL-адрес аутентификации: Конечная точка для сервера авторизации поставщика API, для получения кода аутентификации.
  • URL-адрес токена доступа: Сервер аутентификации провайдера для обмена кодом авторизации на токен доступа.
  • Идентификатор клиента: Идентификатор клиентского приложения, зарегистрированного у поставщика API.
  • Секрет клиента: Секрет клиента, предоставленный вам поставщиком API.
  • Область: Область запрашиваемого доступа, которая может включать несколько значений, разделенных пробелами.
  • Состояние: Непрозрачное значение для предотвращения подделки межсайтовых запросов.
  • Проверка подлинности клиента: Раскрывающийся список — отправьте запрос обычной проверки подлинности в заголовке или учетные данные клиента в теле запроса. После обновления до новой версии измените значение в этом раскрывающемся меню, чтобы избежать проблем с аутентификацией клиента.
Вкладка дополнительных параметров
  • Ресурс: URI, который указывает ресурс или целевую службу, где предполагается использовать маркер.
  • Аудитория: URI, который указывает целевую аудиторию или службу, в которой предполагается использовать токен.

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

Когда вы используете Код авторизации или Неявный тип предоставления , вам будет предложено ввести свои учетные данные для получения токена доступа для использования в последующих запросах. По умолчанию Postman будет отображать всплывающее окно браузера, когда вы нажмете Request Token .В качестве альтернативы вы можете выбрать аутентификацию с помощью веб-браузера по умолчанию в вашей системе. Выберите Авторизовать с помощью браузера , и URL-адрес обратного вызова будет автоматически заполнен, чтобы вернуться в Postman после завершения аутентификации в браузере, чтобы ваши запросы могли использовать токен, возвращенный при успешной аутентификации.

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

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

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

Удаление токена в Postman не отменяет доступ. Только сервер, выпускающий токен, может его отозвать.

Ястреб аутентификации

Аутентификация

Hawk позволяет авторизовать запросы с использованием частичной криптографической проверки.

На вкладке Авторизация для запроса выберите Hawk Authentication из раскрывающегося списка Тип .

Введите свои данные в поля Hawk Auth ID , Hawk Auth Key и Algorithm .При желании вы можете установить дополнительные сведения, но Почтальон попытается сгенерировать для них значения, если это необходимо.

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

Параметры аутентификации Hawk следующие:

  • Hawk Auth ID: Ваше значение идентификатора аутентификации API.
  • Hawk Auth Key: Значение вашего ключа аутентификации API.
  • Алгоритм: Алгоритм хеширования, используемый для создания кода аутентификации сообщения (MAC).
  • Расширенные параметры:

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

Подпись AWS

AWS — это рабочий процесс авторизации для запросов Amazon Web Services. AWS использует настраиваемую схему HTTP, основанную на HMAC с ключом (Hash Message Authentication Code) для аутентификации.

Более подробная информация в официальной документации AWS Signature:

На вкладке Авторизация для запроса выберите Подпись AWS из раскрывающегося списка Тип .

Выберите, куда Postman должен добавить данные авторизации AWS, с помощью раскрывающегося списка Добавить данные авторизации в , выбрав заголовки запроса или URL-адрес.

  • Если вы выберете Заголовки запроса , Почтальон добавит поля с префиксом Авторизация и X-Amz- на вкладке Заголовки .
  • Если вы выберете URL-адрес запроса , Postman добавит данные аутентификации в Params с ключами с префиксом X-Amz- .

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

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

Параметры подписи AWS следующие:

  • AWS Region: Регион, получающий запрос (по умолчанию us-east-1 ).
  • Имя службы: Служба, получающая запрос.
  • Маркер сеанса: Требуется только при использовании временных учетных данных безопасности.

Аутентификация NTLM

Windows Challenge / Response (NTLM) — это процесс авторизации для операционной системы Windows и для автономных систем.

На вкладке Авторизация для запроса выберите NTLM Authentication из раскрывающегося списка Тип .

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

Дополнительные параметры для NTLM-аутентификации:

  • Домен: Домен или хост для аутентификации.
  • Рабочая станция: Имя хоста ПК.

Akamai EdgeGrid

Akamai Edgegrid — помощник авторизации, разработанный и используемый Akamai.

На вкладке Авторизация для запроса выберите Akamai EdgeGrid из раскрывающегося списка Тип .

Введите свой Access Token , Client Token и Client Secret , используя переменные для дополнительной безопасности — вы получите эти данные при регистрации клиентского приложения в Akamai.

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

Для получения информации о получении учетных данных см. Разработчик Akamai — авторизация клиента.

Синхронизация файлов cookie

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

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

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

Включить согласие для областей действия | Okta Developer

Используйте следующие шаги, чтобы отобразить диалоговое окно согласия пользователя как часть запроса OpenID Connect или OAuth 2.0.

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

  1. В консоли администратора выберите Приложения > Приложения .

  2. Выберите приложение OpenID Connect, для которого требуется согласие пользователя.

  3. Выберите вкладку Общие и щелкните Изменить .

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

    Примечание: Если раздел Согласие пользователя не отображается, значит, у вас не включены функции управления доступом к API и согласия пользователя. Чтобы включить эти функции, обратитесь в службу поддержки (открывается в новом окне).

  5. В этом примере мы используем поток Implicit для целей тестирования. В разделе Application выберите Implicit flow, а затем оба Allow ID Token с неявным типом предоставления и Allow Access Token с неявным типом предоставления .

    Для потока кода авторизации тип ответа — , код . Вы можете обменять код авторизации на токен ID и / или токен доступа, используя конечную точку / token .

  6. Нажмите Сохранить .

  7. Чтобы включить согласие для областей, для которых требуется согласие, выберите Security , а затем API .

  8. На вкладке Серверы авторизации выберите в таблице по умолчанию (Пользовательский сервер авторизации). В этом примере мы включаем согласие для областей настраиваемого сервера авторизации по умолчанию.

  9. Выберите вкладку Области .

  10. Щелкните значок редактирования для области телефона . Появится диалоговое окно «Редактировать область».

  11. Выберите Требовать согласия пользователя для этой области и нажмите Сохранить .

Включение согласия с использованием API

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

Обновление приложения

В этом примере показано тело JSON-запроса PUT к существующему приложению OpenID Connect ( https: // $ {yourOktaDomain} / api / v1 / apps / $ {applicationId} ). Запрос обновляет параметр grant_method с TRUSTED (по умолчанию) на REQUIRED . Значение, которое вы указываете для согласия_метод , зависит от значений приглашения и согласия .

Примечание: Проверьте таблицу Settings в Add OAuth 2.0 Клиентское приложение справочника по API приложений для получения информации об этих трех свойствах. В большинстве случаев ТРЕБУЕТСЯ — правильное значение.

Примечание: Вам понадобится applicationId приложения, которое вы хотите обновить. Выполните список приложений, чтобы найти этот идентификатор.

Чтобы включить согласие для области, для которой вы хотите потребовать согласие, необходимо обновить соответствующую область, установив свойство согласия для области с IMPLICIT (по умолчанию) на REQUIRED .

Согласие на обновление области действия

В этом примере показано тело JSON для запроса PUT на настраиваемый сервер авторизации по умолчанию ( https: // $ {yourOktaDomain} / api / v1 / authorizationServers / $ {authServerId} / scopes / $ {scopeId } ), чтобы обновить область видимости телефона . Для запроса вам потребуется следующая информация:

OAuth SSO — JFrog — JFrog Documentation


Использование

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

Вы будете перенаправлены на экран входа в систему соответствующего провайдера.

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


Настройка OAuth

Чтобы получить доступ к настройкам интеграции OAuth, в модуле Администрирование выберите Безопасность | OAuth SSO .


Включить OAuth
Если этот параметр выбран, аутентификация с поставщиком OAuth включена, и система отобразит всех настроенных поставщиков OAuth. Если не отмечено, аутентификация выполняется пользователем / паролем Artifactory.
Автоматическое создание пользователей системы
Если установлено, система автоматически создаст новых пользователей для тех, кто вошел в систему с помощью OAuth, и назначит их группам по умолчанию.
Поставщик по умолчанию

Задает поставщика, через которого различные клиенты (например, npm) должны аутентифицировать свой логин, чтобы получить доступ к платформе JFrog.

Поставщик по умолчанию

В настоящее время только поставщик GitHub Enterprise OAuth может быть определен в качестве поставщика по умолчанию.

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

База настраиваемых URL-адресов

Чтобы настройки OAuth работали, убедитесь, что настроен настраиваемый базовый URL-адрес.

Добавление нового поставщика

Список поставщиков, определенных в Artifactory, отображается в разделе Providers .

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

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

9317 https: // www.googleapis.com/oauth3/v3/token

GitHub.com
GitHub Enterprise
Google
Cloud Foundry UAA
OpenID
Описание

9017 √

9017 √

9322 √

9017 √

Если этот параметр выбран, этот поставщик OAuth включен и появится в диалоговом окне входа в систему.
Имя провайдера


Логическое имя для этого провайдера. Например, «Google OAuth», «GitHub OAuth».

Это должно быть уникальным в рамках платформы JFrog.

Тип провайдера

Тип провайдера.В настоящее время поддерживаются GitHub , Git Enterprise, Google , OpenID и Cloud Foundry .
Идентификатор клиента


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

Предоставляется поставщиком OAuth при настройке учетной записи с ним.

Секрет

Секрет, выделенный вашей организацией провайдером.

Предоставляется поставщиком OAuth при настройке учетной записи с ним.

Домен
X X
X X

Задает фильтр домена, который определяет, из каких доменов пользователи могут проходить аутентификацию.

Обычно это будет ваше доменное имя. Например, jfrog.com

Docker Login
X

X X X Поддержка входа в Docker8 X X X X Поддержка входа в npm
Основной URL-адрес
https: // github.com /

<Базовый URL-адрес сервера>

X X X Базовый URL-адрес сервера Git, который должен использоваться для аутентификации.
URL-адрес аутентификации

https://github.com/login/oauth/authorize

Учетные записи GitHub.com

Любая учетная запись GitHub.com, имеющая доступ к URL-адресу Artifactory, будет разрешена для входа, включая учетные записи, которые находятся за пределами вашего GitHub.com объем организации.

<Базовый URL-адрес сервера> / login / oauth / authorize https://accounts.google.com/o/oauth3/auth <Базовый URL-адрес сервера> / oauth / authorize

URL-адрес, по которому провайдер перенаправляет вас на страницу аутентификации.
URL-адрес API
https://api.github.com/user <Базовый URL-адрес сервера> / api / v3 / user https: // www.googleapis.com/oauth3/v1/userinfo <Базовый URL-адрес сервера> / userinfo

URL-адрес, по которому Artifactory может получить дополнительную информацию, недоступную напрямую через OAuth.
URL-адрес токена
https://github.com/login/oauth/access_token <базовый URL-адрес сервера> / login / oauth / access_token <Базовый URL-адрес сервера> / oauth / token

URL-адрес, на который Artifactory перейдет, чтобы получить токен для использования API.

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

Вы можете передавать параметры запроса вместе с URL-адресом авторизации.

Пример

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

Несколько параметров запроса следует разделять амперсандом.

Пример

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

Привязка существующих учетных записей пользователей

Для входа в систему с использованием любой из учетных записей поставщика OAuth Если у вас уже есть внутренняя учетная запись (не внешние области, такие как LDAP, SAML …) в системе, привяжите свою учетную запись JFrog Platform к соответствующий аккаунт.

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

В разделе Привязка пользователя OAuth выберите Щелкните, чтобы привязать рядом с поставщиком OAuth, с которым вы хотите выполнить привязку.


Создание учетных записей поставщика OAuth

Чтобы использовать аутентификацию OAuth, вам необходимо настроить учетную запись у каждого поставщика OAuth, которого вы хотите использовать, чтобы получить различные параметры (такие как Provider ID и Secret), которые вы будете необходимо настроить интеграцию OAuth в системе.

GitHub OAuth Setup

Внимание! Доступ к GitHub.com Учетные записи

Любая учетная запись GitHub.com, имеющая доступ к URL-адресу платформы JFrog, будет разрешена для входа, включая учетные записи, которые находятся за пределами вашей организации GitHub.com. Это не относится к GitHub Enterprise.

Чтобы настроить свою учетную запись OAuth на GitHub:

  1. Войдите в свою учетную запись GitHub. В настройках личного профиля выберите Applications и нажмите кнопку Вкладка «Приложения для разработчиков».

  2. Щелкните Зарегистрируйте новое приложение.

  3. Задайте имя приложения. Например, JFrog Platform Cloud OAuth.

  4. Задайте URL домашней страницы . Это URL-адрес хоста вашего сервера Artifactory ( https: // / ).
    Например, https://mycompany.jfrog.io/mycompany/

  5. Задайте URL-адрес обратного вызова авторизации следующим образом:

    1. Для локальной установки: http: // / artifactory / api / oauth3 / loginResponse
      Например, http: // mycompany.artifactory.com/artifactory/api/oauth3/loginResponse

    2. Для облака: https: // .jfrog.io / artifactory / api / oauth3 / loginResponse
      Например, https: //mycompany.jfrog.io/artifactory/api/oauth3/loginResponse
  6. Щелкните Зарегистрируйте приложение , чтобы сгенерировать идентификатор клиента и секрет клиента .
    Запишите это; они понадобятся вам для настройки аутентификации OAuth через GitHub на JPD.

Настройка поставщика OAuth Google

Чтобы настроить учетную запись OAuth в Google, выполните следующие действия:

  1. Войдите в Консоль разработчика Google.
  2. Создайте новый проект. Например, «Artifactory OAuth».

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

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

  5. Вернитесь на вкладку Учетные данные , щелкните Добавить учетные данные и выберите Идентификатор клиента OAuth 2.0.

  6. В разделе Создать идентификатор клиента выберите Веб-приложение .

  7. Введите имя и установите URI авторизованного перенаправления
    Для локальной среды: https: // / artifactory / api / auth / oauth3 / loginResponse
    Для облака: https: / / <имя_сервера>. jfrog.io/artifactory/api/oauth3/loginResponse

  8. Щелкните Create , чтобы сгенерировать свой Client ID и Client Secret .

    Запишите это; они понадобятся вам для настройки аутентификации OAuth через Google на платформе JFrog.

Настройка UAA Cloud Foundry

Поддерживается аутентификация OAuth с Cloud Foundry UAA.

Чтобы настроить аутентификацию OAuth с Cloud Foundry UAA, заполните поля по мере необходимости.


Использование безопасного OAuth

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

Если вы хотите использовать OAuth с недоверенным (самоподписанным) сертификатом, см. Раздел «Доверие новому ЦС или самозаверяющему сертификату».


Использование ключа API с пользователями OAuth

Хотя OAuth обеспечивает доступ к пользовательскому интерфейсу, пользователи OAuth также могут сгенерировать ключ API, который можно использовать вместо пароля для базовой аутентификации или в выделенном заголовке REST API, это очень полезно при работе с разными клиентами, например.грамм. docker, npm, maven и т. д. или с помощью Artifactory REST API.

Чтобы разрешить пользователям OAuth доступ к ключу API, необходимо убедиться, что установлены флажки « Автоматическое создание системных пользователей » и « Разрешить созданным пользователям доступ к странице профиля ». Это означает, что пользователи OAuth также сохраняются в базе данных и могут получить доступ к странице своего профиля, чтобы сгенерировать, получить и отозвать свой ключ API.


Использование OAuth при настройке высокой доступности

Протокол OAuth требует, чтобы клиент дал разрешение определенному приложению.JPD перенаправит пользователя на настроенный URL-адрес приложения, и пользователю будет предоставлено одно разрешение.

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

Пример ниже показывает конфигурацию NGINX.

Конфигурация обратного прокси NGINX

 расположение ~ (/ 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;
} 
.