Где проверить одноразовость в OAuth 2.0 Implict Flow? - PullRequest
Новая
       125

Где проверить одноразовость в OAuth 2.0 Implict Flow?

0 голосов
/ 24 апреля 2018

У меня есть следующая архитектура.

enter image description here

Где:

  • Клиент - это одностраничное JavaScript-приложение.
  • Сервер авторизации - это Azure AD.
  • Сервер ресурсов - это служба приложений Azure, использующая Аутентификация Azure AD .
  • Все коммуникации защищены с использованием HTTPS.

Я использую Implicit Flow для доступа к токену доступа JWT из Azure AD. 

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid%20https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&response_mode=fragment
&state=12345
&nonce=678910

Этот токен JWT затем передается на сервер ресурсов в качестве авторизации на предъявителя. Один и тот же токен может быть многократно использован до истечения срока его действия.

В рамках запроса на авторизацию я передаю состояние и одноразовое значение.

В настоящее время я проверяю состояние моего клиента в JavaScript с помощью простого if: 

function isValid() {
    if (token.state !== expectedState) {
        return false;
    }

    ...
}

Если я правильно понимаю, одноразовый номер предназначен для предотвращения атак воспроизведения - что, я полагаю, имел в виду и против моего сервера ресурсов, но, возможно, также против клиента .

Я не уверен, где (или если) мне следует подтвердить одноразовый номер.

На сервере это выглядит неправильно, токен в целом проверяется, и токен предназначен для повторного использования (в течение срока его действия).

На клиенте, кажется, лучшее расположение, но это отличается от проверки состояния?

Ответы [ 2 ]

0 голосов
/ 17 июня 2019

В общем, я бы рекомендовал использовать превосходную сертифицированную oidc-client библиотеку, чтобы сделать это для вас

С Azure AD сложно работать, но у меня есть документированный пример, который работает и который мы использовали на моемпоследняя компания: http://authguidance.com/2017/11/30/azure-active-directory-setup/

С радостью отвечу на любые вопросы, если это поможет ..

0 голосов
/ 24 апреля 2018

Я не уверен, где (или если) мне следует подтвердить одноразовый номер.

Конечно, вы должны подтвердить одноразовый номер. Потому что nonce является обязательным , и оно будет возвращено и содержится в качестве претензии в id_token. Когда вы проверяете id_token, вы просто подтверждаете претензию nonce. Использование одноразового номера означает ослабление атак воспроизведения токена (тот, кто хочет использовать атаку воспроизведения токена, не будет знать одноразовый номер, поэтому у каждого токена есть разные одноразовые номера для определения источника запроса).

Существует четкое объяснение одноразового номера для конечной точки AAD v2:

nonce (обязательно)

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

Итак, вы можете просто проверить id_token для проверки одноразового номера.

а чем отличается проверка состояния?

Да, эффект nonce отличается от состояния. Во-первых, nonce будет возвращен в id_token, и вы можете проверить его при декодировании и проверке id_token. Но state возвращается в ответе, а не в токене. Кроме того, state имеет значение и эффект, отличные от nonce.

state (рекомендуется)

Значение, включенное в запрос, которое также будет возвращено в ответ токена. Это может быть строка любого контента, который вы пожелаете. A случайно сгенерированное уникальное значение обычно используется для предотвращения атаки подделки межсайтовых запросов . Государство также используется для кодирования информация о состоянии пользователя в приложении до произошел запрос аутентификации, например, страница или представление на.

Дополнительно, атака воспроизведения отличается от атак подделки межсайтовых запросов. Вы можете обратиться за более подробной информацией об этих двух атаках. Затем вы поймете, почему nonce находится в токене, а state в ответе.

Проверка правильности одноразового номера (токена) на клиенте

Как правило, вы можете проверить id_token в клиентском коде, но общепринятой практикой является отправка nonce на внутренний сервер и выполнение проверки там.

В соответствии с архитектурой это означает, что проверяет токен как на клиенте, так и на сервере ресурсов. Для SPA мы можем использовать ADAL.js для проверки nonce, id_token, в котором содержится nonce заявление о смягчении атак воспроизведения токенов.

Надеюсь, это поможет!

...