Issuing Verifiable Credentials With Keycloak (OID4VCI)

Keycloak can act as a Verifiable Credential issuer using the OpenID for Verifiable Credential Issuance (OID4VCI) protocol, letting it issue credentials a user stores in a digital wallet and presents elsewhere, completely decoupled from a live login session. This capability exists in Keycloak 26.x as a preview/experimental feature that must be explicitly enabled via a feature flag, which means the APIs and configuration details are actively evolving. Treat everything in this post as an introduction to the concepts and direction of travel, and always consult the current Keycloak documentation and release notes before building on this foundation.

What Are Verifiable Credentials?

A Verifiable Credential (VC) is a tamper-evident, cryptographically signed digital claim. Think of it as the digital equivalent of a physical document, a driver’s licence, a university degree, an employee badge, except that:

• The issuer’s signature is machine-verifiable without calling back to the issuer at presentation time.
• The holder stores it in a digital wallet app and decides when and where to share it.
• A verifier can confirm authenticity and the credential’s claims without a live round-trip to the original authority.

The W3C Verifiable Credentials Data Model defines the underlying structure. OID4VCI and related OpenID protocols define how credentials are delivered and presented using familiar OAuth 2.0/OIDC flows that developers already know, making them a natural fit for identity infrastructure like Keycloak.

If you are new to how OIDC itself works, start with our OpenID Connect explained for developers guide before continuing here.

The Issuer, Holder, and Verifier Triangle

Verifiable Credential systems are built around three actors:

This triangle breaks the traditional hub-and-spoke identity model. In a classic OIDC flow, the verifier must contact the identity provider at authentication time. In a VC flow, the verifier independently checks a cryptographic signature, the issuer is not involved in the presentation at all.

That decoupling has significant practical value:

• Offline verification: A verifier can check a credential without internet access (think airport kiosks, physical access systems).
• Privacy preservation: The user shares only what is necessary; with Selective Disclosure (more on formats below) they can prove a single claim without revealing the entire credential.
• Reduced issuer load: The issuer is only involved once, at issuance. Subsequent presentations do not generate traffic back to the issuer.
• Reusable KYC: A bank verifies a user once; the resulting VC can be presented to other regulated services, reducing re-verification cost.

Why This Matters Now: EUDI Wallets and the EU Digital Identity Framework

The European Union’s eIDAS 2.0 regulation requires EU member states to provide citizens with a digital identity wallet, the EU Digital Identity (EUDI) wallet. The underlying technical framework, the Architecture Reference Framework (ARF), specifies OID4VCI as the issuance protocol and OID4VP (OpenID for Verifiable Presentations) as the presentation protocol.

The EUDI rollout timeline has been subject to revision, check the official European Commission publications for current status rather than relying on any date written here. What is clear is that the direction is set: European identity infrastructure is moving toward wallet-based credential exchange, and OID4VCI is the issuance mechanism.

Beyond Europe, the same patterns are relevant to:

• Healthcare credentialing: Issuing practitioner licences or patient consent records as portable VCs.
• Education: Issuing verifiable diplomas and transcripts directly from an institution’s identity system.
• Employee onboarding: Issuing workplace access credentials that can be verified by third-party systems without a real-time LDAP/SCIM lookup.
• B2B SaaS: Allowing partners to present attestations about their compliance posture or organisational role.

OID4VCI vs OID4VP: Issuance vs Presentation

These two protocols are complementary and frequently mentioned together, but they serve opposite directions of the credential flow.

OID4VCI (OpenID for Verifiable Credential Issuance): defined by the OpenID Foundation, describes how a wallet obtains credentials from an issuer. The wallet authenticates to the issuer (using standard OAuth 2.0 flows), and the issuer returns one or more signed credentials.

OID4VP (OpenID for Verifiable Presentations): the companion spec, describes how a wallet presents credentials to a verifier. The verifier sends a request; the wallet responds with a presentation containing the relevant credential(s).

Keycloak’s current experimental work focuses on the issuer role via OID4VCI. Supporting the verifier role (OID4VP) is a separate concern, typically implemented by the relying party application or a dedicated verification service.

For a deeper look at how OAuth 2.0 flows underpin all of this, see our OAuth 2.0 visual guide for developers.

Credential Formats: SD-JWT VC and mdoc

OID4VCI is format-agnostic, it describes the issuance protocol, not the credential format itself. Two formats dominate current implementations.

SD-JWT VC (Selective Disclosure JWT Verifiable Credentials)

SD-JWT VC is a compact, JWT-based credential format that supports selective disclosure. The issuer includes hashed “disclosures” for individual claims; the holder selectively reveals only the claims required for a given presentation.

Example: a national identity credential might contain name, date of birth, address, and nationality. When presenting to a service that only needs proof of age, the holder reveals only the date of birth disclosure, the verifier cannot infer the other fields from the presentation.

SD-JWT VC aligns closely with the IETF draft draft-ietf-oauth-sd-jwt-vc and is the format most naturally suited to OID4VCI implementations built on JWT infrastructure, including Keycloak.

mdoc / ISO 18013-5

mdoc (Mobile Document) is the format defined by ISO/IEC 18013-5, originally designed for mobile driver’s licences (mDL). It uses CBOR encoding rather than JSON/JWT and is required for certain EUDI wallet use cases, particularly those involving physical document equivalents like driving licences.

mdoc support adds implementation complexity, especially for server-side issuers accustomed to JWT tooling. For most developer-facing use cases today, SD-JWT VC is the more approachable starting point.

Keycloak as a Verifiable Credential Issuer

Keycloak 26.x includes experimental support for acting as a VC issuer via OID4VCI. This capability is gated behind the oid4vc-vci feature flag and is not enabled by default.

This is a preview feature. The exact admin console paths, configuration keys, REST API endpoints, and supported credential formats are actively changing between Keycloak releases. The description below is intentionally conceptual, do not use specific configuration snippets from blog posts (including this one) as a substitute for the official Keycloak documentation.

Enabling the Feature

Keycloak’s experimental features are enabled via the --features startup flag (or the equivalent environment variable in container deployments). To enable OID4VCI support, you add oid4vc-vci to the list of enabled features when starting Keycloak.

For a general reference on how Keycloak feature flags work, consult the Keycloak Server Administration Guide for your specific version. The feature flag name and enabling mechanism should be verified against the release notes for the exact Keycloak version you are running.

What Enabling the Feature Unlocks

When the OID4VCI feature is active, Keycloak gains additional capability in its realm configuration to:

• Define one or more credential types that it can issue, including the format (SD-JWT VC is the primary supported format in current preview releases) and the claims to include.
• Expose a Credential Issuer Metadata endpoint, which wallets use to discover the issuer’s capabilities (analogous to the OIDC discovery endpoint).
• Handle credential requests from wallets via the OID4VCI pre-authorized code flow and/or the authorization code flow.
• Sign issued credentials using the realm’s cryptographic keys.

The OID4VCI protocol reuses standard OAuth 2.0 grant types, which means Keycloak’s existing token infrastructure, client configuration, scopes, authentication flows, carries over in large part. This is one of the design advantages of OID4VCI: it does not require a completely separate authorization server.

Connecting to Existing OIDC Infrastructure

Because OID4VCI is built on OAuth 2.0, it integrates naturally with Keycloak’s existing realm setup. A wallet authenticates using a standard authorization code flow or pre-authorized code flow, receives an access token, and exchanges it for a Verifiable Credential at the Credential Endpoint.

From Keycloak’s perspective, the credential request is similar to a UserInfo request, but instead of returning JSON claims, Keycloak returns a signed credential document. The claims population and signing happen server-side, using the realm’s keys and the credential type configuration you define.

This means that if you have already configured Keycloak as an OIDC provider, realm, clients, users, custom attributes, much of that groundwork translates into the VC issuance setup. Understanding what Keycloak is and how it works is a prerequisite for getting value from the OID4VCI feature.

The OID4VCI Issuance Flow at a High Level

Even without diving into experimental Keycloak configuration details, it is useful to understand the protocol flow conceptually, because this is the user journey your implementation must support.

Pre-Authorized Code Flow

The pre-authorized code flow is designed for use cases where the user has already completed authentication on a separate channel (for example, via a web browser) and needs to transfer a credential to their wallet.

1. The issuer (Keycloak) generates a pre-authorized code and a credential offer.
2. The credential offer is presented to the user as a QR code or deep link.
3. The user scans the QR code with their wallet app.
4. The wallet sends a token request to the issuer using the pre-authorized code.
5. The issuer returns an access token (and optionally a nonce for proof-of-possession).
6. The wallet sends a credential request, including a proof that it holds the private key for the credential’s subject key binding.
7. The issuer returns the signed credential.

Authorization Code Flow

The authorization code flow follows the standard OIDC authorization code flow: the wallet initiates an authorization request, the user authenticates via Keycloak’s login page (or an existing session is used), and the wallet ultimately exchanges an authorization code for a credential.

This flow is better suited to cases where the credential issuance is initiated from the wallet itself rather than from a web session.

For a deep understanding of token-level mechanics that apply here, see our guide on Keycloak token exchange.

Should You Use This in Production Today?

This is the most important question in this article, and the honest answer is: probably not as a default production feature, but yes as an evaluation or pilot feature.

Here is a realistic assessment:

When it makes sense to start now:

• You are building for EUDI wallet compliance and need to understand the protocol.
• You are running a pilot or proof-of-concept in a non-production environment.
• You want to influence the direction of Keycloak’s OID4VCI implementation by testing early and filing issues.
• You are evaluating whether OID4VCI fits your architecture before committing to a production rollout.

When to wait:

• You need a stable, production-supported API with a versioning guarantee.
• Your use case does not specifically require portable, wallet-held credentials, standard OIDC SSO already solves the problem for most web and mobile app authentication scenarios.

For production SSO and authentication, Keycloak’s battle-tested OIDC and SAML implementations remain the right tool. See our SSO implementation guide for those patterns.

What to Watch as This Evolves

The Keycloak project’s approach to OID4VCI is worth tracking closely if this space is relevant to you.

Keycloak release notes: Each Keycloak release includes a migration guide and notes on feature flag changes. When the OID4VCI feature moves from preview to default or supported, that signals production readiness. Always check the Keycloak release notes for your target version.

OpenID Foundation specifications: OID4VCI, OID4VP, and the related Self-Issued OpenID Provider (SIOPv2) spec are all active working group outputs. The OpenID Foundation’s GitHub hosts the latest editor’s drafts.

EUDI ARF updates: The European Commission publishes updates to the EUDI Architecture Reference Framework; these updates directly influence what OID4VCI features are required for EUDI wallet compliance.

SD-JWT VC IETF draft: Monitor the IETF OAuth working group’s progress on the SD-JWT VC draft for format stabilization signals.

Frequently Asked Questions

Can Keycloak issue verifiable credentials?

Yes. Keycloak 26.x includes experimental support for acting as an OID4VCI credential issuer via the oid4vc-vci feature flag. When enabled, Keycloak can issue cryptographically signed credentials in SD-JWT VC format to compatible digital wallets. This is a preview feature, meaning the configuration and APIs are subject to change between releases. Consult the current Keycloak documentation for the exact setup steps for your version.

What is OID4VCI?

OID4VCI (OpenID for Verifiable Credential Issuance) is a protocol specification from the OpenID Foundation that defines how a wallet obtains a Verifiable Credential from an issuer. It reuses OAuth 2.0 grant types, specifically the authorization code flow and a pre-authorized code flow, so it is compatible with existing OAuth 2.0/OIDC infrastructure. The full specification is published at the OpenID Foundation website.

Is Keycloak’s verifiable credential support production-ready?

As of Keycloak 26.x, the OID4VCI feature is explicitly marked as experimental/preview. It must be enabled via a feature flag and is not part of Keycloak’s default supported feature set. The APIs and configuration format are evolving. This makes it well-suited for evaluation, pilots, and EUDI compliance exploration, but organizations should exercise caution before depending on it in production systems. Monitor Keycloak release notes for when the feature graduates from preview status.

What is the difference between OID4VCI and OID4VP?

OID4VCI handles the issuance direction: a wallet obtaining a credential from an issuer. OID4VP (OpenID for Verifiable Presentations) handles the presentation direction: a wallet presenting one or more credentials to a verifier. Both protocols are specified by the OpenID Foundation and are used together in complete Verifiable Credential ecosystems. Keycloak’s experimental work targets the issuer role (OID4VCI); the verifier role (OID4VP) is typically implemented by the relying party or a dedicated verification service.

How does OID4VCI relate to the EUDI wallet?

The EU Digital Identity (EUDI) wallet initiative, established under eIDAS 2.0, mandates OID4VCI as the issuance protocol and OID4VP as the presentation protocol for EU member state digital identity wallets. The EUDI Architecture Reference Framework (ARF) specifies these protocols at a technical level. Organizations building services that need to accept or issue EUDI-compatible credentials must implement OID4VCI-conformant issuers and verifiers. For current EUDI rollout timelines and ARF versions, consult the official European Commission digital identity pages.

Getting Started: Next Steps

The conceptual map for exploring Keycloak OID4VCI looks like this:

1. Build your Keycloak baseline. If you do not have a running Keycloak instance, start with our complete Keycloak guide and set up a realm, clients, and users using standard OIDC. The OID4VCI feature builds on top of this foundation.

2. Read the Keycloak documentation for your version. Navigate to the Keycloak documentation for the exact version you are running and search for OID4VCI or Verifiable Credentials. The documentation reflects the current state of the feature flag; blog posts, including this one, lag behind releases.

3. Enable the feature in a non-production environment. Start the Keycloak server with the oid4vc-vci feature flag enabled (consult the docs for the correct syntax for your deployment method) and explore the resulting admin console options.

4. Test with a wallet. Several open-source wallet implementations support OID4VCI. The OpenID Foundation and EUDI project maintain lists of conformant implementations. Testing against a real wallet is the fastest way to understand the end-to-end flow.

5. Follow the spec and release notes. Subscribe to Keycloak release announcements and the OpenID Foundation mailing lists to track when the feature stabilizes.

Conclusion

Verifiable Credentials represent a meaningful shift in how digital identity works, from a hub-and-spoke model where every authentication requires a live call to an identity provider, to a portable, wallet-held model where credentials travel with the user and can be verified offline, selectively disclosed, and reused across contexts.

Keycloak is early in its OID4VCI journey. The experimental feature in Keycloak 26.x demonstrates a clear architectural commitment: as the standards mature and the EUDI wallet ecosystem grows, Keycloak’s existing role as a trusted OIDC and SAML provider will extend naturally into the credential issuance layer.

For now, the right posture is to evaluate and learn. Run pilots. Understand the protocol. Build familiarity with credential formats and wallet interactions. By the time the feature graduates from preview to production-ready, teams that have done this groundwork will be positioned to move quickly.

If you want to focus on the implementation rather than the infrastructure, a managed Keycloak environment removes the operational overhead so you can concentrate on exploring emerging capabilities like OID4VCI. Skycloak’s managed Keycloak plans give you a production-grade Keycloak instance with the flexibility to enable preview features in a controlled way.