Процессы авторизации OAuth

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

1. Вы открываете мобильное приложение Salesforce.
2. Отображается напоминание о проверке подлинности, в котором вы вводите имя пользователя и пароль.
3. Мобильное приложение Salesforce отправляет ваши регистрационные данные в Salesforce и инициирует процесс авторизации OAuth.
4. Salesforce отправляет маркеры доступа и обновления мобильного приложения в качестве подтверждения успешной проверки пользователя и мобильного приложения.
5. Вы утверждаете запрос на предоставление доступа к мобильному приложению Salesforce.
6. Запускается мобильное приложение Salesforce.

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

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

Потоки авторизации OAuth и приложения внешних клиентов

Все процессы авторизации OAuth, за исключением процесса утверждения SAML, требуют определения приложения внешнего клиента. Инфраструктура внешнего клиентского приложения позволяет стороннему приложению интегрироваться в Salesforce посредством API и стандартных протоколов, например, SAML, OAuth и OpenID Connect. Внешние клиентские приложения используют эти протоколы для проверки подлинности, авторизации и интеграции внешних приложений и поставщиков услуг. Внешние приложения, интегрированные в Salesforce, могут работать на платформе успеха клиента, устройствах, подписках SaaS или других платформах. В примере выше мобильное приложение Salesforce интегрируется с вашей организацией посредством приложения внешнего клиента.

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

Сценарии использования потока авторизации OAuth

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

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

• Потоки удостоверения без заголовка
  Вы можете использовать Headless Identity API для настройки входа, регистрации, входа без пароля и прочего для внеплатформенного приложения. Потоки Headless Identity доступны только внешним пользователям, также известным как клиенты и партнеры.
• Создание нативного взаимодействия единой регистрации в приложении
  С помощью дополнительного параметра в потоке веб-сервера OAuth 2.0 и потоке пользователя-агента можно создать взаимодействие единой регистрации (SSO), чувствующее, что стороннее приложение интегрировано с внешним поставщиком удостоверений. С помощью этого процесса вы связываете поток OAuth с потоком SSO, сохраняя контроль взаимодействия в приложении. Этот параметр поддерживается для сайтов Experience Cloud, поэтому вы можете использовать эту возможность для добавления единого входа в внедрение Headless Identity. Этот параметр также поддерживается для «Моего домена».
• Процесс веб-сервера OAuth 2.0 для интеграции веб-приложения
  Чтобы интегрировать внешнее веб- приложение в Salesforce API, используйте процесс веб- сервера OAuth 2.0, который внедряет тип предоставления кода авторизации OAuth 2.0. С помощью этого процесса сервер, размещающий веб-приложение, должен иметь возможность защитить удостоверение приложения внешнего клиента, определенное кодом клиента и секретом клиента.
• Процесс пользователя-агента OAuth 2.0 для интеграции на ПК или в мобильное приложение
  С помощью процесса пользователя-агента OAuth 2.0 пользователи авторизуют настольный компьютер или мобильное приложение для доступа к данным посредством внешнего или встроенного обозревателя. Клиентские приложения, выполняемые в обозревателе посредством языка сценариев, например, JavaScript, также могут использовать этот поток. Этот поток использует тип скрытого предоставления OAuth 2.0.
• Процесс проверки подлинности маркера обновления OAuth 2.0 для возобновленных сеансов
  Процесс маркера обновления OAuth 2.0 продлевает маркеры доступа, выданные процессом веб-сервера OAuth 2.0 или процессом пользователя-агента OAuth 2.0.
• Процесс обмена маркерами OAuth 2.0
  Если Salesforce является только одним компонентом архитектуры, содержащей центрального поставщика удостоверений, а также несколько приложений и микросервисов, используйте поток обмена маркерами OAuth 2.0 для упрощения схем интеграции. С помощью этого потока обменяйте маркеры от внешних поставщиков удостоверений на маркеры Salesforce и предоставьте доступ к данным Salesforce.
• Авторизация OAuth 2.0 и управление сеансами для гибридных приложений
  Управление веб-сеансами для гибридных приложений сложное с типичным процессом проверки подлинности пользователя-агента или маркера обновления. В этих потоках гибридное приложение устанавливает запрошенные cookie-файлы домена и соединяет маркер доступа с веб-сеансом. Но маркер доступа и веб-сеанс не связаны в этих потоках. Вместо этого необходимо отслеживать, когда истекает срок действия маркеров доступа и обновления и когда истекает срок действия веб-сеанса, а потом вручную перемыкать сеанс во избежание прерывания обслуживания. Во избежание этого сложного процесса используйте потоки гибридного приложения OAuth 2.0. Эти потоки связывают маркеры доступа и обновления с веб-сеансом, чтобы предоставить гибридным приложениям прямое управление веб-сеансами.
• Процесс носителя OAuth 2.0 JWT для интеграции между серверами
  Иногда требуется авторизовать серверы для доступа к данным без интерактивного входа при каждом обмене информацией. Для этих случаев можно использовать процесс носителя веб-маркера OAuth 2.0 JSON (JWT). Этот поток использует сертификат для подписи запроса JWT и не требует явного взаимодействия с пользователем. Однако, этот поток требует предварительного утверждения клиентского приложения.
• Поток регистрационных данных клиента OAuth 2.0 для интеграции между серверами
  Иногда требуется прямой общий доступ к информации между двумя приложениями без вмешательства пользователя. Для этих сценариев можно использовать поток регистрационных данных клиента OAuth 2.0. В этом потоке клиентское приложение обменивает свои регистрационные данные клиента, определенные во внешнем клиентском приложении - его ключ пользователя и секрет пользователя - на маркер доступа. Этот поток устраняет необходимость четкого взаимодействия с пользователем, но требует указания пользователя интеграции для выполнения интеграции. Вы можете использовать этот поток в качестве более безопасной альтернативы потоку имени пользователя и пароля OAuth 2.0.
• Динамическая регистрация клиента OpenID Connect для внешних шлюзов API
  Хотя это не типичный процесс авторизации, вы можете использовать динамическую регистрацию клиента OpenID Connect, чтобы включить экземпляр Salesforce в качестве независимого сервера авторизации OAuth для защиты ресурсов, размещенных во внешнем шлюзе API.
• Создание первичного маркера доступа
  Динамическая регистрация клиента OpenID Connect позволяет клиентам OAuth 2.0, связанным приложениям, напрямую регистрировать связанные приложения в Salesforce. Для проверки подлинности этих запросов на регистрацию клиента Salesforce требует первичный маркер доступа.
• Интроспекция маркера OpenID Connect
  В процессе авторизации интроспекция маркера позволяет всем связанным приложениям OAuth проверять текущее состояние маркера доступа или обновления OAuth 2.0. Сервер ресурса или связанные приложения отправляют код и секрет клиентского приложения на сервер авторизации, запуская процесс авторизации OAuth. В рамках этого процесса сервер авторизации проверяет или интроспектирует маркер доступа клиентского приложения. Если маркер доступа является актуальным и действительным, клиентское приложение получает доступ.
• Процесс устройства OAuth 2.0 для интеграции IoT
  Чтобы интегрировать приложения, выполняемые на устройствах с ограниченными возможностями ввода или отображения, например, интеллектуальные телевизоры, бытовая техника и другие устройства IoT, используйте поток устройства OAuth 2.0. Приложения командной строки также могут использовать этот поток. Пользователи могут подключать эти приложения к Salesforce, открывая обозреватель на устройстве с расширенными возможностями ввода, например, на ПК или мобильном устройстве.
• Процесс проверки подлинности маркера актива OAuth 2.0 для обеспечения безопасности подключенных устройств
  Чтобы интегрировать устройства IoT в Salesforce API, используйте процесс маркера актива OAuth 2.0. Маркеры активов - это открытый маркер проверки подлинности JWT на основе стандартов для проверки и безопасности запросов от подключенных устройств. Маркеры актива определяют устройство в фоновой службе, обрабатывающей поток данных и событий из устройства. Данные маркеры позволяют регистрировать данные устройства на Salesforce Platform и связывать устройство с данными Salesforce CRM о клиенте, организации или контакте.
• Демонстрация потока маркера актива
  Для быстрой демонстрации маркеров активов можно использовать демонстрационное приложение проводника по маркерам активов. Демонстрационное приложение упрощает первичное получение маркера доступа и его обмен на маркер актива.
• Процесс проверки подлинности имени пользователя и пароля OAuth 2.0 для специальных сценариев
  Поток имени пользователя и пароля можно использовать для авторизации клиента посредством связанного приложения, в котором уже есть регистрационные данные пользователя. Однако, мы рекомендуем избегать этого потока, поскольку он передает регистрационные данные туда-сюда. Рекомендуем использовать его только при наличии высокой степени Trust между ответственным за ресурс и клиентом, клиентом является стороннее приложение, Salesforce размещает данные и другие типы грантов недоступны. В этих случаях настройте полномочия пользователя для минимизации доступа и защиты сохраненных регистрационных данных от несанкционированного доступа.
• Блокировка потоков авторизации для повышения безопасности
  Потоки пользователя-агента OAuth 2.0 и имени пользователя и пароля считаются небезопасными и не рекомендуются. Для повышения безопасности настоятельно рекомендуем блокировать эти потоки в Salesforce, чтобы предотвратить их использование разработчиками для создания новых интеграций. Если ваша организация создана в выпуске Summer ‘23 или более позднем, поток имени пользователя и пароля блокируется по умолчанию. При необходимости включите поток имени пользователя и пароля. При наличии существующих интеграций, использующих поток пользователя-агента или имени пользователя и пароля, обновите их на более безопасный поток OAuth 2.0. Вы также можете заблокировать код авторизации и поток регистрационных данных, используемый для безопасной настройки процесса входа без заголовка. Также можно блокировать определенные потоки, не использующие расширение PKCE.
• Процесс утверждения носителя OAuth 2.0 SAML для ранее авторизованных приложений
  С помощью процесса утверждения носителя OAuth 2.0 SAML клиент может использовать предыдущую авторизацию посредством связанного приложения, предоставив подписанное утверждение SAML 2.0 для запроса маркера доступа OAuth. Цифровая подпись, примененная к утверждению SAML, проверяет подлинность авторизованного приложения. Утверждение SAML — это XML-маркер безопасности, выдаваемый поставщиком удостоверений и используемый поставщиком услуг. Поставщик услуг полагается на свое содержимое для идентификации темы утверждения в целях безопасности.
• Поток утверждения SAML для доступа к API
  Поток утверждения SAML является альтернативой для организаций, использующих SAML для доступа к Salesforce и желающих получить доступ к API таким же образом. Клиенты могут объединиться с API посредством утверждения SAML, аналогично объединению с Salesforce для единой веб-регистрации (Web SSO). Вы можете использовать этот поток утверждения без связанного приложения.
• Ошибки авторизации OAuth 2.0
  Во время авторизации OAuth могут произойти ошибки. Например, пользователь запрещает доступ к связанному приложению или параметры запроса некорректны. При возникновении ошибок сервер авторизации отправляет ошибку на URL-адрес обратного вызова с кодом ошибки.
• Процесс OAuth 1.0.A
  Если ваша организация использует протокол OAuth 1.0.A, используйте этот поток авторизации для интеграции клиента посредством связанного приложения с Salesforce API.
• Коды ошибок авторизации OAuth 1.0.A
  Во время авторизации могут произойти ошибки. Например, недопустимый URL-адрес обратного вызова. При возникновении ошибок во время процесса OAuth 1.0.A Salesforce возвращает код ошибки.