---
status: "proposed"
decision-makers: {list everyone involved in the decision}
---

<!-- markdownlint-disable-next-line MD025 -->
# Replace Keycloak with OpenBao as OIDC Provider

## Context and Problem Statement

The EDP currently relies on Keycloak as the OpenID Connect (OIDC) provider to handle authentication and authorization. However, Keycloak is fairly complex and has quite some maintenance overhead, which will leads to increased operational effort. We need to determine if replacing Keycloak with OpenBao, a tool we already use for secrets management and which may support OIDC capabilities, can streamline our architecture and reduce these operational burdens.

## Decision Drivers

- Simplify architecture by reducing the number of tools in our ecosystem.
- Reduce operational complexity and maintenance overhead to improve team efficiency.
- Ensure seamless integration with existing systems, particularly leveraging our current use of OpenBao.
- Maintain or enhance security and performance to meet platform requirements.

## Considered Options

- Keep using Keycloak
- Replace Keycloak with OpenBao

## Decision Outcome

Chosen option: "Replace Keycloak with OpenBao", because it enables us to consolidate identity and secrets management into a single tool, reducing operational complexity, improving integration with our existing infrastructure, and potentially enhancing performance, provided OpenBao can meet our OIDC needs.

### Consequences

- *Good*, because it simplifies the architecture by reducing the number of tools we need to manage.
- *Good*, because it may lower operational costs by eliminating a separate system and leveraging an existing open-source tool.
- *Bad*, because additional configuration or development might be required to ensure OpenBao fully supports all necessary OIDC features.
- *Bad*, because relying on a single tool for both identity and secrets management increases risk if OpenBao encounters issues.

### Confirmation

- Conduct a proof-of-concept to validate that OpenBao can effectively serve as an OIDC provider meeting our platform’s requirements.
- Validate that all EDP components support the Authorization Code Flow
- Review the design and implementation with the development team to confirm alignment with this decision.

## Pros and Cons of the Options

### Keep using Keycloak

Keycloak is a mature, feature-rich OIDC provider widely used for authentication and authorization.
- *Good*, because it offers extensive OIDC features, including support for single sign-on and various authentication protocols.
- *Good*, because it is already integrated into our platform, minimizing immediate changes.
- *Bad*, because its complexity increases configuration and maintenance efforts.
- *Bad*, because maintaining it as a separate tool adds to operational overhead.

### Replace Keycloak with OpenBao

OpenBao, a fork of HashiCorp Vault, is currently used for secrets management and may be configurable as an OIDC provider.
- *Good*, because consolidating identity and secrets management into one tool simplifies our architecture.
- *Good*, because it leverages our existing OpenBao deployment, potentially improving integration and reducing costs.
- *Bad*, because OpenBao may not natively support all advanced OIDC features provided by Keycloak, such as comprehensive user management.
- *Bad*, because its community and documentation for OIDC use cases may be less robust compared to Keycloak.

## More Information

Before finalizing this decision, we must verify OpenBao’s OIDC capabilities against our specific authentication and authorization requirements, such as user federation and token issuance for our development platform. The team should also assess the long-term implications of relying heavily on OpenBao and consider revisiting this decision if significant gaps in OIDC functionality are identified during the proof-of-concept phase.