Блог

В источниках, таких как этот сайт, спонсируемый Okta (см. Раздел «Настройка для каждого запроса»), упоминается, что параметр redirect_uri запроса авторизации НИКОГДА НЕ ДОЛЖЕН содержать часть динамического запроса (например, для использования с сопоставлением сеансов).

Цитата:

Сервер должен отклонять любые запросы на авторизацию с URL-адресами перенаправления, которые не являются точным совпадением с зарегистрированным URL.

Наш поставщик OAuth AZ — BIG-IP F5. Мы настраиваем его, и они, похоже, соответствуют приведенному выше представлению.

Наш клиент — это веб-приложение, созданное в другом месте, и они, похоже, не следуют вышеуказанному правилу. Вот полное представление конечной точки авторизации (отредактировано): https://ourownF5host.ca/f5-oauth2/v1/authorize?client_id=theIDofOurClientamp;redirect_uri=https://ourClientAppHostname/ClientRessource/Ressource?SessionId=76eab448-52d1-4adb-8eba-e9ec1b9432a3amp;state=2HY-MLB0ST34wQUPCyHM-Aamp;scope=RessourceDataamp;response_type=code

Они используют redirect_uri с форматом, подобным (я не указываю urlencode здесь, для простоты): redirect_uri=https://ourClientAppHostname/ClientRessource/Ressource ?SessionID=SOMELONGSESSIONID, при этом значение SOMELONGSESSIONID отличается для каждого вызова.

Мы ГЛУБОКО изучили RFC6749 (OAuth2) и нашли это в разделе 3.1.2.2:

Сервер авторизации ДОЛЖЕН потребовать от клиента предоставить
полный URI перенаправления (клиент МОЖЕТ использовать
параметр запроса «состояние» для достижения настройки для каждого запроса). Если требование
регистрации полного URI перенаправления невозможно,
сервер авторизации ДОЛЖЕН потребовать регистрации
схемы URI, полномочий и пути (позволяя клиенту динамически изменять
только компонент запроса URI перенаправления при запросе
авторизации).

Что я понимаю и хотел бы проверить здесь, так это то, что первый источник, Okta и F5 принимают ТОЛЬКО первую часть правила выше и требуют, чтобы uri перенаправления был ПОЛНОСТЬЮ зарегистрирован без какой-либо динамической части.

Прав ли я, утверждая, что они (Okta и F5) НЕ соответствуют второй части отрывка, ссылаясь на то, что они должны «разрешать клиенту динамически изменять только компонент запроса URI перенаправления при запросе авторизации«?

ИЛИ существует ли какое-либо официальное исправление / эволюция RFC6749, которое гарантирует позицию обеих компаний в области проектирования?

TL; DR:

Нет, uri перенаправления должен быть статическим по соображениям безопасности. Если клиенту необходимо сохранить state связь между запросом авторизации и его асинхронным ответом, используйте параметр OAuth 2.0 state .

Длинная версия :

RFC6749 (начальная спецификация OAuth 2.0) была опубликована в 2012 году, и с тех пор ландшафт безопасности OAuth сильно изменился.

В RFC6819, обзоре безопасности OAuth 2.0 от 2013 уже упоминалось, что отказ от динамически созданных URI перенаправления был хорошим способом защиты от атак XSS и олицетворения клиента.

OpenID Connect, с 2014 года, широко используемое расширение OAuth 2.0 с возможностями аутентификации, уже учитывает эту рекомендацию и требует точного сопоставления строк для всех URI перенаправления.

Текущий проект рекомендации по наилучшей практике обеспечения безопасности OAuth 2.0 подтверждает это, применяя предварительную регистрацию redirect_uris и предписывая использовать простое сравнение строк с помощью AS при проверке redirect_uri, переданного в запросе. Таким образом, динамический redirect_uri не должен использоваться.

Ваш клиент определенно совершает неверный шаг, используя redirect_uri в качестве «хранителя состояния» между запросом авторизации и ответом, используя динамически созданный SessionID атрибут внутри redirect_uri. Что OAuth2.0 имеет специальный запрос на авторизацию параметр для той цели, которая является «государство«. Клиент должен использовать его. AS добавит это состояние в параметры redirect_uri при выдаче ответа, поэтому клиент сможет найти это состояние внутри ответа.

Надлежащий запрос на авторизацию будет:

https://youras/authorize?client_id=your_client_idamp;response_type=codeamp;state=SOMELONGSTATEamp;redirect_uri=https://somehost/authcallback

Ответ будет выглядеть следующим образом: https://somehost/authcallback?state=SOMELONGSTATEamp;code=anazcode

Таким образом, redirect_uri является статическим, поэтому простого сравнения строк достаточно для проверки этого uri на стороне AS. Любой алгоритм, более сложный, чем простое сравнение строк, будет подвержен недостаткам безопасности.

Похоже, что здесь смешаны две вещи: URL, на который вы ссылаетесь:

  https://somehost/authcallback?state=SOMELONGSTATEamp;scope=someobjecttypeamp;response_type=code
  

предполагает, что вы перепутали URI перенаправления (он же URL обратного вызова, как указано в имени пути в URL) Клиента с конечной точкой авторизации сервера авторизации.

Только конечная точка авторизации будет принимать параметры, как предложено, и может содержать, например, динамическое state значение. URI перенаправления клиента не будет содержать, например, тип ответа.

redirect_uri Параметр может быть добавлен к запросу авторизации, который затем должен быть сопоставлен описанным вами способом. После подтверждения соответствия Сервер авторизации перенаправит обратно в URI перенаправления, добавив параметры code и state .

Обновить (после изменения вопроса):

OAuth 2.0 RFC6749 допускает динамический параметр (SessionID), хотя это не считается лучшей практикой. Однако, если ваш клиент является клиентом OpenID Connect, это не разрешено, поскольку спецификация OpenID Connect («профиль» OAuth 2.0) блокирует соответствие URI перенаправления «точному», и в этом случае вам придется настроить все возможные идентификаторы сеанса.