| 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), grant_type=urn:veriqa:params:oauth:grant-type:confirmation: клиент, создавший транзакцию подтверждения, после исхода confirmed обменивает её на id_token подтвердившего. Включается на уровне клиента опцией AllowConfirmationTokenGrant, которая требует AllowClientCredentials и openid в AllowedScopes. Каждая транзакция погашается однократно; refresh token не выпускается. См. привязку с сервера |
| Scope’ы | ✅ | openid, profile, email, phone, offline_access, channel и avatar — два последних — собственные scope Veriqa, не стандартные. avatar гейтит claim picture, который отдаётся только через userinfo. Claim, который каталог Veriqa:ScopesClaims относит к 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). value и values не применяются. Параметр, который не является JSON-объектом или чей член id_token либо userinfo — не объект, отвергается с 400 oidc_request_invalid. Discovery публикует claims_parameter_supported: false (значение OpenIddict по умолчанию); параметр при этом обрабатывается |
