Аутентификация с помощью 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

  1. Создайте учетную запись Azure здесь: https://azure.microsoft.com.
  2. Начните с перехода к 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