Аутентификация с помощью API Azure может позволить вашему веб-приложению получать доступ к службам от имени ваших пользователей. В этой статье я покажу, как настроить приложение для аутентификации с помощью API Azure с использованием OAuth 2.0; многие показанные примеры будут относиться к настройке интеграции между Infisical и Azure, но вы сможете адаптировать их к своему собственному варианту использования.
На высоком уровне нам потребуется настроить приложение в Azure и настроить поток OAuth 2.0 в нашем приложении для работы с ним.
Не знаете, что такое OAuth? Ознакомьтесь с букварем здесь.
Общий обзор
Прежде чем мы углубимся в то, как мы можем реализовать OAuth 2.0 с Azure для доступа к API Azure, полезно понять высокоуровневый поток, с которым мы будем иметь дело.
- (A) Перенаправить пользователя из браузера в Azure: пользователь нажимает кнопку в браузере и перенаправляется в Azure, где он может предоставить приложению доступ к своей учетной записи Azure.
- (B) Вернуть пользователя из Azure обратно в браузер: после предоставления пользователь перенаправляется обратно в браузер с помощью
code
. - (C) Выполните обмен кодом-токеном: отправьте
code
из браузера на сервер для обмена с Azure. После обмена мы должны получить обратноaccess_token
иrefresh_token
от Azure. - (D) Используйте токен доступа для отправки запросов к API Azure:С помощью
access_token
мы теперь можем отправлять запросы к API Azure от имени пользователя. Если срок действияaccess_token
истекает, мы можем использоватьrefresh_token
для получения новогоaccess_token
.
Полезные советы. Теперь мы готовы реализовать OAuth 2.0 с Azure для доступа к API Azure.
Настройка приложения в Azure
- Создайте учетную запись Azure здесь: https://azure.microsoft.com.
- Начните с перехода к Azure Active Directory › Регистрация приложений, чтобы создать новое приложение.
3. Создайте приложение.
В форме установите для URI перенаправления значение https://your-domain.com/integrations/azure-key-vault/oauth2/callback
; вы, конечно, можете выбрать свой собственный URL-адрес перенаправления на основе желаемой структуры маршрутизации. Это URL-адрес, на который Azure перенаправит пользователя обратно после того, как он разрешит приложению доступ к своей учетной записи Azure.
Обратите внимание: чтобы включить поддержку мультитенантных вариантов использования OAuth, вам необходимо зарегистрировать свою организацию в партнерской сети Microsoft (MPN).
4. Получите Идентификатор приложения (клиента) в разделе «Обзор» и создайте Секрет клиента в разделе «Сертификат и секреты» для вашего приложения Azure.
Настройка веб-приложения для работы с приложением Azure
5. Перенаправьте пользователя в Azure из интерфейса вашего веб-приложения.
В интерфейсе вашего веб-приложения создайте кнопку, при нажатии которой инициируется поток OAuth 2.0, перенаправляя пользователей в Azure, чтобы они могли войти в систему и предоставить веб-приложению доступ к своей учетной записи Azure. Обработчик кнопки должен содержать следующую логику:
// the client id from azure const client_id = "" // create a CSRF token and store it locally const state = crypto.randomBytes(16).toString("hex"); localStorage.setItem("latestCSRFToken", state); // redirect the user to azure const link = `https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=${client_id}&response_type=code&redirect_uri=${window.location.origin}/integrations/azure-key-vault/oauth2/callback&response_mode=query&scope=https://vault.azure.net/.default openid offline_access&state=${state}`; window.location.assign(link);
Обратите внимание: в зависимости от вашего варианта использования вы можете определить область доступа иначе, чем указано выше; Подробнее об этом можно прочитать здесь. В этом примере область — https://vault.azure.net/.default openid offline_access
, специфичная для моего приложения, где я хочу, чтобы пользователь разрешил приложению доступ к своей службе Azure Key Vault.
В любом случае, здесь мы генерируем токен CSRF, который будет сохранен в локальном хранилище и отправлен в Azure как параметр state
; это связано с смягчением атаки межсайтовой подделки запросов (CSRF), которая выходит за рамки этой статьи.
Обратите внимание, что вам следует заменить redirect_uri
в link
на тот, который вы зарегистрировали на шаге 3 в Azure. Когда пользователи нажимают кнопку, они должны быть перенаправлены в Azure.
6. Проверьте параметр state
при перенаправлении пользователя обратно в веб-приложение и отправьте code
на серверную часть.
Поскольку Azure перенаправит пользователя обратно на redirect_uri
после того, как он войдет в систему и предоставит веб-приложению доступ к своей учетной записи Azure, вам необходимо создать для него страницу для обработки следующей части потока OAuth 2.0. Здесь redirect_uri
будет иметь параметры code
и state
; вам следует проанализировать эти параметры из URL-адреса и убедиться, что параметр state
соответствует токену CSRF в локальном хранилище из шага 4. Если все в порядке, вы можете приступить к отправке code
в серверную часть веб-приложения для выполнения обмена code-token
.
const { code, state } = queryString.parse(router.asPath.split("?")[1]); // validate the state parameter if (state !== localStorage.getItem("latestCSRFToken") { localStorage.removeItem("latestCSRFToken"); // send the code to the backend const res = await axios.post("/api/oauth-token", { code }); }
7. Обменяйте code
на access_token
и refresh_token
.
Теперь в серверной части приложения вам следует выполнить обмен токенами кода с конечной точкой API Azure.
const res = await axios.post( "https://login.microsoftonline.com/common/oauth2/v2.0/token", new URLSearchParams({ grant_type: "authorization_code", code: code, scope: "https://vault.azure.net/.default openid offline_access", client_id: process.env.AZURE_CLIENT_ID, client_secret: process.env.AZURE_CLIENT_SECRET, redirect_uri: `your-domain/integrations/azure-key-vault/oauth2/callback`, }) ); const access_token = res.data.access_token; // used to access the Azure API const refresh_token = res.data.refresh_token; // used to refresh the access token const expires_in = res.data.expires_in; // used to know when to refresh the access token
8. Используйте access_token
для доступа к API Azure от имени пользователя.
Теперь вы можете получить доступ к API Azure от имени пользователя, включив access_token
в запросы, отправляемые к API.
9. Если срок действия access_token
истечет, активируйте refresh_token
, чтобы получить новый access_token
.
На шаге 7 вы, возможно, заметили, что Azure возвращает два дополнительных поля, которые мы привязываем к переменным refresh_token
и expires_in
. Поскольку access_token
— это кратковременные учетные данные аутентификации для Azure API, поле expires_in
помогает нам сообщить, когда истечет срок их действия. Как только мы узнаем, что срок действия токена доступа истек, мы можем сделать специальный запрос API, содержащий refresh_token
, к конечной точке токена, чтобы получить новый access_token
и продолжить доступ к API Azure от имени пользователя, как на шаге 8.
const res = await axios.post( "https://login.microsoftonline.com/common/oauth2/v2.0/token", new URLSearchParams({ scope: "openid offline_access", refresh_token: refreshToken, grant_type: "refresh_token", client_id: process.env.AZURE_CLIENT_ID, client_secret: process.env.AZURE_CLIENT_SECRET, }) ); const access_token = res.data.access_token; const refresh_token = res.data.refresh_token; const expires_in = res.data.expires_in;
Вот и все!
Теперь вы знаете, как настроить приложение для аутентификации с помощью API Azure с использованием OAuth 2.0.
Советы
Правильная реализация OAuth 2.0 имеет решающее значение для безопасности вашего приложения и пользователей.
Вот несколько практических советов, которые вам следует иметь в виду:
- Не прописывайте Идентификатор клиента и Секрет клиента для своего приложения где-либо в базе кода. Вместо этого вам следует безопасно хранить как Идентификатор клиента, так и Секрет клиента вашего приложения, предпочтительно в виде переменных среды приложения. Более того, вам следует рассмотреть возможность хранения этих учетных данных в секретном менеджере, таком как Infisical, и возвращать их обратно на сервер во время выполнения.
- Не выполняйте обмен кодом-токеном OAuth несколько раз. Обмен должен выполняться один раз, после чего вам следует управлять токенами обновления и доступа для выполнения всех последующих запросов к API службы. Поскольку с этими токенами следует обращаться безопасно, как и в моем предыдущем совете, вам также следует рассмотреть возможность хранения их в секретном менеджере.
— -
Infisical — платформа управления секретами с открытым исходным кодом.
Infisical (9,4 тыс.+ ⭐️) помогает тысячам команд и организаций хранить и синхронизировать секреты внутри своей команды и инфраструктуры.
Репозиторий GitHub: https://github.com/Infisical/infisical