OIDC and OAuth 2.0 support

This page answers “what exactly do you support” in one list, so the answer does not have to be assembled from several sections.

Supported

Capability	Status	Note
Authorization Code Flow	✅	`code` is the only supported `response_type`
PKCE	✅	`S256` only. `plain` is refused for every client; a public client without PKCE is refused
Refresh tokens	✅	via the `offline_access` scope, enabled per client
UserInfo	✅	`/connect/userinfo`
Discovery + JWKS	✅	`/.well-known/openid-configuration`, `/.well-known/jwks`
Token revocation (RFC 7009)	✅	`/connect/revoke`
Token introspection (RFC 7662)	✅	`/connect/introspect`. The response carries metadata only — `active`, `iss`, `sub`, `jti`, `client_id`, `token_type`, `exp`, `iat`, `nbf`; the user’s claims come from `/connect/userinfo`. Enabled per client with `AllowIntrospection`, confidential clients only. A client with this permission sees `sub` and `client_id` of tokens issued to other clients, so grant it only to your own confidential clients
`iss` in the authorization response (RFC 9207)	✅	mix-up protection
Client authentication	✅	`client_secret_basic`, `client_secret_post`, `private_key_jwt`
`response_mode`	✅	`query` (the default), `fragment` and `form_post` — all three advertised in discovery are applied; `form_post` responds with an auto-posting page that submits the response to your `redirect_uri`
`prompt`	✅	`consent`, `login`, `none`, `select_account`
`id_token` signing	✅	`RS256`
Client Credentials Grant	✅	only for creating confirmation transactions server-to-server (`POST /api/transaction/confirmation`) and reading their result; enabled per client with `AllowClientCredentials`, confidential clients only
Confirmation token grant	✅	Veriqa’s own extension grant (RFC 6749 §4.5), `grant_type=urn:veriqa:params:oauth:grant-type:confirmation`: the client that created a confirmation transaction exchanges it, once the outcome is `confirmed`, for the `id_token` of the person who confirmed. Enabled per client with `AllowConfirmationTokenGrant`, which requires `AllowClientCredentials` and `openid` in `AllowedScopes`. Each transaction is redeemed once; no refresh token is issued. See linking from your server
Scopes	✅	`openid`, `profile`, `email`, `phone`, `offline_access`, `channel` and `avatar` — the last two are Veriqa’s own, not standard. `avatar` gates the `picture` claim, which is served through userinfo only. A claim the `Veriqa:ScopesClaims` catalog lists under a scope goes into both the `id_token` and the access token (and so into userinfo) when that scope is granted, and into no token otherwise — on sign-in, on a refresh and in the confirmation token grant alike, whether the channel gave the value or Veriqa collected it. A custom claim the catalog does not list goes into the access token only
The `claims` parameter (OIDC Core §5.5)	✅	requirement levels only — the claim set is still driven by scopes. A claim in the `id_token` or `userinfo` member marked `essential: true` becomes required: the sign-in does not complete without it; any other claim named there is asked of the user, who may decline. A claim counts only when a requested scope covers it, and a claim Veriqa cannot complete stays issue-if-available (see `Level` in `Veriqa:ScopesClaims`). `value` and `values` are not enforced. A parameter that is not a JSON object, or whose `id_token` or `userinfo` member is not an object, is refused with `400 oidc_request_invalid`. Discovery publishes `claims_parameter_supported: false` (the OpenIddict default); the parameter is honored regardless

Not supported

Listed explicitly so that you do not plan around something absent.

Capability	Status	What it means in practice
RP-Initiated Logout (`end_session_endpoint`)	❌	signing out of your application does not end the session on the Veriqa side; `revocation_endpoint` exists for revoking tokens, which is a different operation
Pushed Authorization Requests (RFC 9126)	❌	—
JWT-Secured Authorization Request (JAR)	❌	the `request` and `request_uri` parameters are not accepted
DPoP	❌	tokens are not bound to a sender key
mTLS-bound tokens	❌	—
Dynamic Client Registration	❌	clients are declared in configuration
Device Authorization Grant	❌	—
Resource indicators (RFC 8707)	❌	Veriqa registers no resources, so a `resource` parameter is rejected with `invalid_target` for any value — that is the default and it does not change. Clients written for Microsoft Entra ID send the parameter regardless; for those, the per-client quirk `drop-resource-parameter` strips it before validation instead of granting any resource

Known deviations

Two places where Veriqa’s behavior differs from what a client may expect. Knowing about them in advance is enough. The access token is an opaque reference token, not a readable JWT. The client receives an identifier; the token content stays in the Veriqa OpenIddict database. The refresh token has the same form. A client that tries to parse the access token as a JWT gets an error or a log warning — Grafana, for one, behaves this way. It does not affect sign-in: the access token is meant for the Veriqa server, and the client takes session content from the id_token and UserInfo. An API of yours checks an access token through introspection, not by keys. Earlier builds issued the access token as an encrypted JWE; such tokens are still accepted until they expire. The scope parameter is rejected in the token request. RFC 6749 §4.1.3 does not define it for grant_type=authorization_code, and the Veriqa server follows it strictly. Two known clients send it anyway — the openid-connect-generic plugin for WordPress and omniauth_openid_connect for GitLab; how to clear it on their side is described on the WordPress and Veriqa in business systems pages.

Certification

There is no formal OpenID Foundation certification. WordPress, Drupal, Nextcloud, Keycloak, Discourse and Odoo verify and accept the Veriqa id_token signature against JWKS — six independent implementations — and Keycloak configures itself entirely from the Veriqa discovery document.

Get started

Samples

Guides

Use cases

Ready-made recipes

Cloud

Reference

Releases

OIDC and OAuth 2.0 support

Supported

Not supported

Known deviations

Certification

​Supported

​Not supported

​Known deviations

​Certification

Supported

Not supported

Known deviations

Certification