Поделиться через

Общие сведения о неявном потоке предоставления OAuth2 в Azure Active Directory (AD)

  • Статья

Предупреждение

В этом руководстве используется устаревшая конечная точка Azure Active Directory версии 1.0. Для новых проектов используйте платформу удостоверений Майкрософт.

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

Что такое неявное предоставление OAuth2

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

Неявное предоставление OAuth2 — это один из типов предоставления авторизации. Он позволяет клиенту получить маркер доступа (а при использовании OpenId Connect — маркер id_token) напрямую из конечной точки авторизации без взаимодействия с конечной точкой маркера и без проверки подлинности для клиента. Этот вариант разработан для приложений на основе JavaScript, работающих в веб-браузере. По стандартной спецификации OAuth2 маркеры возвращаются в виде фрагмента универсального кода ресурса (URI). Это обеспечивает доступность маркеров для кода JavaScript в клиенте, но гарантирует, что они не будут перенаправляться на сервер. В неявном предоставлении OAuth2 конечная точка авторизации выдает токены доступа непосредственно клиенту с помощью URI перенаправления, который был предоставлен ранее. Также этот вариант удобен тем, что избавляет от любых междоменных вызовов, которые необходимы при обращении приложения JavaScript к конечной точке маркера.

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

Подходящие сценарии для неявного предоставления OAuth2

В спецификации OAuth2 указано, что неявное предоставление разработано для поддержки приложений агента пользователя, то есть выполняемых в браузере приложений JavaScript. Определяющей характеристикой таких приложений является использование кода JavaScript для доступа к ресурсам сервера (обычно к веб-API) и для обновления пользовательского интерфейса приложения. Рассмотрим такие приложения, как Gmail или Outlook Web Access. При выборе входящего сообщения, чтобы отобразить новое выделение, изменяется только область визуализации, в то время как остальная часть страницы остается неизменной. В этом заключается их отличие от традиционных веб-приложений на основе перенаправления, в которых при каждом действии пользователя выполняется обратная передача всей страницы и полная отрисовка нового ответа сервера.

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

Приложения на основе перенаправления традиционно защищают свои запросы с помощью файлов cookie, но этот метод не очень хорошо подходит для приложений JavaScript. Файлы cookie действуют только для того домена, в котором они были созданы, тогда как вызовы JavaScript могут направляться и в другие домены. И такая ситуация возникает довольно часто, например, для любых приложений, которые вызывают API-интерфейсы Microsoft Graph, Office или Azure. Все эти службы интерфейсов расположены за пределами домена, из которого получено приложение. Все чаще в приложениях JavaScript не бывает серверной части, а для реализации ее бизнес-функций полностью используются сторонние веб-API.

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

  • Маркеры можно получать безопасно, не выполняя междоменные вызовы. Обязательная регистрация URI перенаправления, на который возвращаются маркеры, гарантирует, что они не будут направлены в неправильное расположение.
  • Приложения JavaScript могут получать любое необходимое количество маркеров доступа для обращения к любому количеству веб-API без ограничений по доменам.
  • Возможности HTML5, например управления сеансом или локальным хранилищем, предоставляют полный контроль над кэшированием и управлением временем существования маркеров, тогда как управление файлами cookie является непрозрачным для приложения.
  • Маркеры доступа неуязвимы к атакам с подделкой межсайтовых запросов (CSRF)

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

Тем не менее приложения JavaScript используют другой механизм обновления маркеров доступа, который не предусматривает многократное запрашивание учетных данных пользователя. Для выполнения новых запросов маркеров к конечной точке авторизации Azure AD приложение может использовать скрытый элемент iframe. Пока в браузере открыт сеанс в домене Azure AD (т. е. сохраняется файл cookie сеанса), при запросе проверки подлинности не нужно взаимодействие с пользователем.

Эта модель дает приложению JavaScript возможность независимо обновлять маркеры доступа и даже получать новые для новых API (при условии, что пользователь ранее согласился на это). Это избавляет от накладных расходов на получение, обслуживание и защиту такого ценного артефакта, как маркер обновления. Управление файлом cookie сеанса Azure AD, т. е. артефактом, который позволяет выполнять автоматическое обновление маркера доступа, происходит вне приложения. У этого подхода есть и другое преимущество: пользователь может выйти из Azure AD, используя любое из приложений, с помощью которого был выполнен вход в Azure AD, запущенного в любой из вкладок браузера. При этом удаляется файл cookie сеанса Azure AD, и приложение JavaScript автоматически теряет возможность обновлять маркеры для пользователя, выполнившего выход.

Совместимость неявного предоставления с приложением

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

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

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

Дальнейшие действия