> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Поддержка OIDC и OAuth 2.0

> Что из спецификаций реализовано, чего нет, какие отклонения известны и есть ли формальная сертификация.

Эта страница отвечает на вопрос «что именно вы поддерживаете» одним списком, чтобы не собирать
ответ по разделам.

## Что поддерживается

| Возможность | Состояние | Примечание |
| - | - | - |
| Authorization Code Flow | ✅ | единственный поддерживаемый `response_type` — `code` |
| PKCE | ✅ | только `S256`. `plain` не принимается ни от кого; public-клиент без PKCE получает отказ |
| Refresh Tokens | ✅ | по scope `offline_access`, включается на уровне клиента |
| UserInfo | ✅ | `/connect/userinfo` |
| Discovery + JWKS | ✅ | `/.well-known/openid-configuration`, `/.well-known/jwks` |
| Token Revocation (RFC 7009) | ✅ | `/connect/revoke` |
| Token Introspection (RFC 7662) | ✅ | `/connect/introspect`. Ответ несёт только метаданные — `active`, `iss`, `sub`, `jti`, `client_id`, `token_type`, `exp`, `iat`, `nbf`; claims пользователя отдаёт `/connect/userinfo`. Включается на уровне клиента опцией `AllowIntrospection`, только для confidential-клиента. Клиент с этим разрешением видит `sub` и `client_id` токенов, выданных другим клиентам, поэтому выдавайте его только своим confidential-клиентам |
| `iss` в ответе авторизации (RFC 9207) | ✅ | защита от смешивания провайдеров |
| Аутентификация клиента | ✅ | `client_secret_basic`, `client_secret_post`, `private_key_jwt` |
| `response_mode` | ✅ | `query` (умолчание), `fragment` и `form_post` — применяются все три, объявленные в discovery; `form_post` отвечает страницей автопоста, которая отправляет ответ на ваш `redirect_uri` |
| `prompt` | ✅ | `consent`, `login`, `none`, `select_account` |
| Подпись `id_token` | ✅ | `RS256` |
| Client Credentials Grant | ✅ | только для серверного создания транзакций подтверждения (`POST /api/transaction/confirmation`) и чтения их результата; включается на уровне клиента опцией `AllowClientCredentials`, только для confidential-клиента |
| Grant выдачи токена по подтверждению | ✅ | собственный extension grant Veriqa ([RFC 6749 §4.5](https://datatracker.ietf.org/doc/html/rfc6749#section-4.5)), `grant_type=urn:veriqa:params:oauth:grant-type:confirmation`: клиент, создавший транзакцию подтверждения, после исхода `confirmed` обменивает её на `id_token` подтвердившего. Включается на уровне клиента опцией `AllowConfirmationTokenGrant`, которая требует `AllowClientCredentials` и `openid` в `AllowedScopes`. Каждая транзакция погашается однократно; refresh token не выпускается. См. [привязку с сервера](/docs/ru/scenarios/channel-linking#привязка-с-сервера-без-входа) |
| Scope'ы | ✅ | `openid`, `profile`, `email`, `phone`, `offline_access`, `channel` и `avatar` — два последних — собственные scope Veriqa, не стандартные. `avatar` гейтит claim `picture`, который отдаётся только через userinfo. Claim, который каталог [`Veriqa:ScopesClaims`](/docs/ru/reference/configuration#veriqascopesclaims) относит к scope, попадает и в `id_token`, и в access token (а значит, и в userinfo), когда этот scope выдан, и ни в один токен иначе — одинаково при входе, при refresh и в grant выдачи токена по подтверждению, дал ли значение канал или его добрала Veriqa. Собственный claim, которого в каталоге нет, попадает только в access token |
| Параметр `claims` (OIDC Core §5.5) | ✅ | только уровни требований — состав claim'ов по-прежнему задаётся scope'ами. Claim в члене `id_token` или `userinfo` с пометкой `essential: true` становится обязательным: без него вход не завершается; любой другой названный там claim запрашивается у пользователя, и тот может отказаться. Claim учитывается, только если его покрывает запрошенный scope, а claim, который Veriqa не может добрать, остаётся выдаваемым при наличии (см. `Level` в [`Veriqa:ScopesClaims`](/docs/ru/reference/configuration#veriqascopesclaims)). `value` и `values` не применяются. Параметр, который не является JSON-объектом или чей член `id_token` либо `userinfo` — не объект, отвергается с `400 oidc_request_invalid`. Discovery публикует `claims_parameter_supported: false` (значение OpenIddict по умолчанию); параметр при этом обрабатывается |

## Чего нет

Перечислено явно, чтобы вы не планировали на отсутствующем.

| Возможность | Состояние | Что это значит на практике |
| - | - | - |
| RP-Initiated Logout (`end_session_endpoint`) | ❌ | выход из приложения не завершает сессию на стороне Veriqa; для отзыва токенов есть `revocation_endpoint` — это другая операция |
| Pushed Authorization Requests (RFC 9126) | ❌ | — |
| JWT-Secured Authorization Request (JAR) | ❌ | параметры `request` и `request_uri` не принимаются |
| DPoP | ❌ | токены не привязываются к ключу отправителя |
| Привязка токенов к mTLS-сертификату | ❌ | — |
| Dynamic Client Registration | ❌ | клиенты объявляются конфигурацией |
| Device Authorization Grant | ❌ | — |
| Индикаторы ресурса (RFC 8707) | ❌ | в Veriqa ресурсы не регистрируются, поэтому параметр `resource` отвергается с `invalid_target` при любом значении — это дефолт, и он не меняется. Клиенты под Microsoft Entra ID шлют параметр всё равно; для них квирк уровня клиента [`drop-resource-parameter`](/docs/ru/guides/client-compatibility) снимает его до валидации, не выдавая никакого ресурса |

## Известные отклонения

Два места, где поведение Veriqa отличается от того, что клиент может ожидать. Их достаточно знать
заранее.

**Access token — непрозрачный reference-токен, а не читаемый JWT.** Клиент получает идентификатор,
а содержимое токена остаётся в базе OpenIddict на стороне Veriqa. Refresh token устроен так же.
Клиент, который попробует разобрать access token как JWT, получит ошибку или предупреждение в логе —
так, например, ведёт себя Grafana. На вход это не влияет: access token предназначен серверу Veriqa,
а не клиенту, и содержимое сессии клиент берёт из `id_token` и UserInfo. Ваш API проверяет access
token через [интроспекцию](#что-поддерживается), а не по ключам. Прежние сборки выдавали access
token зашифрованным JWE; такие токены принимаются до истечения.

**Параметр `scope` в token-запросе отвергается.** [RFC 6749 §4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3)
не предусматривает его при `grant_type=authorization_code`, и сервер Veriqa следует этому строго. Два известных
клиента его всё же шлют — плагин `openid-connect-generic` у WordPress и `omniauth_openid_connect`
у GitLab; как это снимается на их стороне, написано на страницах
[WordPress](/docs/ru/integrations/wordpress) и [Veriqa в рабочих системах](/docs/ru/integrations/apps).

## Сертификация

**Формальной сертификации OpenID Foundation нет.** Подпись `id_token` по JWKS проверяют и
принимают WordPress, Drupal, Nextcloud, Keycloak, Discourse и Odoo — шесть независимых реализаций;
Keycloak настраивается целиком из discovery-документа Veriqa.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.