Блог

Я работаю над собственным приложением OAuth с перенаправлением интерфейса обратной связи и пытаюсь согласовать RFC6749 (Платформа авторизации OAuth 2.0) с RFC8252 (OAuth 2.0 для собственных приложений).:

В RFC6749 спецификация требует использования абсолютного URI в качестве конечной точки перенаправления клиента (раздел 3.1.2).:

URI конечной точки перенаправления ДОЛЖЕН быть абсолютным URI … URI конечной точки НЕ ДОЛЖЕН включать компонент фрагмента.

Однако в RFC8252, по-видимому, есть исключение. В спецификации указано, что любой порт может использоваться для URI перенаправления IP с обратной связью (раздел 7.3):

Сервер авторизации ДОЛЖЕН разрешить указывать любой порт во время запроса URI перенаправления IP-адресов с обратной связью, чтобы клиенты, которые получают доступный временный порт от операционной системы во время запроса, могли его использовать.

И указывает, что URI перенаправления IP с обратной связью будут поддерживаться (Приложение A.):

Серверы OAuth, поддерживающие собственные приложения, должны: …

3. Поддержка URI перенаправления IP-адресов с обратной связью. Это необходимо для поддержки настольных операционных систем.

RFC8252 также предоставляет разъяснения по регистрации (раздел 8.4):

Серверы авторизации ДОЛЖНЫ требовать, чтобы клиенты регистрировали свой полный URI перенаправления (включая компонент пути) и отклоняли запросы на авторизацию, указывающие URI перенаправления, который точно не совпадает с тем, который был зарегистрирован; исключением являются циклические перенаправления, где требуется точное соответствие, за исключением компонента URI порта.

Таким образом, я понимаю, что правильное поведение сервера авторизации OAuth 2.0 с собственным клиентом приложения состоит в том, чтобы:

1. Требуется регистрация URI перенаправления обратной связи (т. е. http://127.0.0.1/oauth2redirect/example-provider ), возможно, с подстановочным портом :*
2. При запросе GET to /authorize сопоставьте параметр redirect_uri запроса с зарегистрированным URI, но разрешите указать любой порт (т. Е. http://127.0.0.1:61023/oauth2redirect/example-provider будет принято)

Я что-нибудь здесь упускаю? Является ли это ожидаемым поведением для сервера авторизации OAuth 2.0 с зарегистрированным собственным приложением?

Для настольных приложений обычно требуется найти свободный порт во время выполнения, а затем запустить сервер обратной связи по URL-адресу, например http://localhost:8000, без какого-либо пути. Этот прослушиватель существует только по одной причине-для получения ответа на вход.

Теоретически вы можете зарегистрироваться http://localhost в качестве URI перенаправления для клиента, и любой порт будет работать, хотя я очень редко видел, чтобы это поддерживалось серверами авторизации.

Вот мой пример кода, чтобы показать, как это выглядит.Поэтому мое приложение регистрирует три конкретных URL-адреса перенаправления для портов 8001-8003.

Вы правы, что следует регистрировать только точные URL-адреса, чтобы избежать открытых уязвимостей перенаправителя. Поведение RFC8252 для настольных приложений и нескольких портов является особым случаем. Вы можете либо использовать его, либо зарегистрировать несколько URI перенаправления с разными портами.

Другой вариант-использовать частные схемы URI для настольных приложений (лично я предпочитаю это). Мобильные приложения должны использовать URI перенаправления HTTPS как наиболее безопасный вариант — это необходимо для приложений финансового уровня.