RFC 9126 — Pushed Authorization Requests — Versola Docs
/docs
До 1.00.7.5versola.ioGitHub
RUEN

RFC 9126 — Pushed Authorization Requests

OAuth 2.0 Pushed Authorization Requests (PAR)

Спецификация: RFC 9126

Через Pushed Authorization Requests клиент отправляет содержимое authorization request напрямую на authorization server аутентифицированным back-channel запросом и получить взамен request_uri. Через user agent проходит только эта ссылка, поэтому запрос нельзя прочитать или подменить по пути, а его размер не ограничен длиной URL.

Статус

Реализован частично. Отмечено пунктов: 15 из 17.

Pushed Authorization Request Endpoint

  • POST /par — принимает параметры authorization request в формате application/x-www-form-urlencoded
  • Аутентификация клиента — те же методы, что и на token endpoint (client_secret_basic, client_secret_post, private_key_jwt по RFC 7523, а также tls_client_auth и self_signed_tls_client_auth по RFC 8705)
  • Параметр request_uri в pushed request отклоняется (PushedAuthorizationSpec)
  • Полная валидация authorization request до любого взаимодействия с пользователем, включая отказ для code_challenge_method=plain
  • 201 Created с Cache-Control: no-store и 401 с WWW-Authenticate, если аутентификация клиента не удалась
  • 405 Method Not Allowed с заголовком Allow: POST для любого метода кроме POST (PushedAuthorizationSpec)
  • 413 Content Too Large для тела больше 8 KiB (par.max-request-size, по умолчанию 8192 байта), проверка до разбора тела
  • 429 Too Many Requests — ограничение частоты запросов по клиенту не реализовано
  • Параметр request (объекты запроса JAR) — клиент может отправить подписанный объект запроса вместо обычных form-параметров

client_id обязателен в теле pushed request и должен совпадать с аутентифицированным клиентом.

Пример

POST /par HTTP/1.1
Host: id.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

response_type=code&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile&state=af0ifjsldkj
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store

{
  "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
  "expires_in": 60
}

Ссылка request_uri содержит 256 бит энтропии и по умолчанию действительна 60 секунд (настраивается через par.request-uri-ttl). В базе хранится только keyed hash ссылки, поэтому доступа к дампу базы недостаточно для повторного использования pushed request.

Authorization Request

  • Параметр request_uri на /authorize — полностью заменяет содержимое pushed request; client_id при этом по-прежнему обязателен
  • request_uri_parameter_supported: true в discovery означает только ссылки из PAR; URL, размещенный клиентом, отклоняется
  • Привязка к клиенту, отправившему запрос — несовпадающий client_id отклоняется
  • Одноразовое использование — ссылка удаляется при обработке authorization request (PushedAuthorizationSpec)
  • Истекшие ссылки отклоняются

Параметры, переданные вместе с request_uri на authorization endpoint, игнорируются: приоритет имеет pushed payload.

Error Response

Ошибки используют формат token endpoint из RFC 6749 §5.2. Поскольку pushed request обрабатывается до взаимодействия с пользователем, ошибки валидации, которые обычно передаются редиректом обратно клиенту, возвращаются прямо в теле ответа:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_request",
  "error_description": "The request_uri parameter must not be provided to the pushed authorization request endpoint"
}

Authorization Server Metadata

  • pushed_authorization_request_endpoint — публикуется в документе метаданных сервера
  • require_pushed_authorization_requests — не реализовано как метаданные сервера; требование задается для отдельного клиента (см. ниже), а не для всего развертывания

Client Metadata

  • require_pushed_authorization_requests (§6.2) — клиент с этим флагом получает invalid_request, если его запрос приходит на /authorize без request_uri (PushedAuthorizationSpec)

Не реализовано

  • Redirect URI, задаваемые для отдельного запроса (RFC 9126 §2.4) — redirect_uri по-прежнему должен точно совпадать с зарегистрированным для клиента
  • Ограничение частоты запросов с 429 Too Many Requests

На тенанте fapi2 pushed request обязателен для каждого клиента с redirect URI; см. FAPI 2.0.

Куда смотреть

Справочник OpenAPI содержит спецификацию PAR, а профили безопасности говорят, когда PAR обязателен.