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

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

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

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

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

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

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

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

Приложения, которые доводят использование подхода на основе JavaScript до крайности, называются одностраничными приложениями или СПА. Идея заключается в том, что эти приложения служат только начальной HTML-странице и связанной JavaScript, причем все последующие взаимодействия управляются вызовами веб-API, выполняемыми с помощью JavaScript. Однако гибридные подходы, где приложение в основном управляется через postback, но выполняет периодические вызовы JS, являются не редкостью — обсуждение использования неявного потока также актуально для таких подходов.

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

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

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

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

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

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

Подходит ли неявное разрешение для моего приложения?

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

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

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

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

• Узнайте , как интегрировать приложение с Azure AD для получения дополнительной глубины в процессе интеграции приложений.