[FEATURE] Support for OAuth2/OpenID Connect Integration (Azure Entra ID, Keycloak, etc.) in Webchat

[emanzat]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

We would like to request the implementation of a feature that allows the webchat to integrate with an external authentication and authorization server (e.g., OAuth2, OpenID Connect).

❓ Problem Statement / Motivation

Currently, the webchat platform does not provide built-in support for user authentication or authorization via external identity providers. This limitation restricts the ability to securely manage access to the chat interface, particularly in enterprise environments where identity federation and SSO (Single Sign-On) mechanisms are required. As a result, organizations cannot leverage their existing IAM (Identity and Access Management) infrastructure, such as Azure Entra ID (formerly Azure AD), Keycloak, or other OAuth2/OpenID Connect providers, to control and audit access to the chat service.

💡 Proposed Solution

Add support for authentication and authorization via standard protocols such as OAuth 2.0 and OpenID Connect. This feature should allow administrators to configure one or more identity providers (e.g., Azure Entra ID, Keycloak, Auth0) so that users must authenticate before accessing the webchat. Key capabilities would include:

Configurable OIDC endpoints (issuer, client ID, client secret, scopes)

Redirect-based login flow

Token validation and user session handling

Role or claim-based access control
Integration hooks or events for post-login user data enrichment

This would make the webchat more suitable for enterprise use cases and align with security best practices for user identity and access management.

🔄 Alternatives Considered

No response

🎯 Affected Service(s)

None

📚 Additional Context

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature

[dimetron]

I think we had a discussion in context of user login for a2a and how it will work with OpenID. Some considerations:
Do we want to have this code inside kagent or use external.

• use gateway or dex as openid proxy https://dexidp.io/

• have simple implementation which we can borrow from kiali ? https://kiali.io/docs/configuration/authentication/

WDYT?

[emanzat]

@dimetron Thanks for your reply!

Yes, I agree that we need to enable authentication when accessing the KAgent dashboard. The idea is to have a login mechanism to secure the dashboard with role-based access control (RBAC). For example:

• Admins should have full access to configure and manage agents.
• Regular users should only be able to access and use the agents already configured by the admins( view)

This separation would provide a better
security model and make the platform more suitable for shared or multi-user environments

Regarding the implementation, I think adopting the OpenID Connect strategy used by Kiali is a good choice. It’s simple, proven, and should be easy to adapt to KAgent dashboard.

Thank you

[marcinkubica]

how about https://github.com/oauth2-proxy/oauth2-proxy sidecar?

[emanzat]

@marcinkubica Using OAuth2-Proxy is a good solution for applications that do not have a built-in OAuth2 mechanism. However, if it is possible to integrate OAuth2 directly into the application itself, that is preferable. Doing so avoids introducing an additional component, which helps reduce complexity and saves resources such as configuration overhead, RAM, and CPU usage.

[marcinkubica]

@emanzat

Using OAuth2-Proxy is a good solution for applications that do not have a built-in OAuth2 mechanism.

Adding your own security solution also adds a security risk compared to an already hardened existing one ( let's assume oauth2 proxy (or a sidecar of user's choice) is as such)

if is possible to integrate OAuth2 directly into the application itself, that is preferable. Doing so avoids introducing an additional component,

Whether a mechanism is built-in or not, the additional component is introduced the same.
Further down the line, not introducing the component opens the capability for users to utilise their existing security infrastructure, like meshes. - example implementation

[emanzat]

@marcinkubica
Thanks for the clarification — your points are valid, especially regarding the security maturity of solutions like OAuth2-Proxy and how they can integrate well into existing service meshes or infrastructure.

That said, in this specific case, I'm only looking to protect a single internal application, not something exposed to the public internet or part of a larger service ecosystem. Since the app is intended for internal use only, and not publicly accessible, the security surface is already limited.

Also, if I don’t integrate OAuth2 directly into the application, it becomes more difficult to properly manage role-based access control (RBAC) — for example, restricting certain views to regular users and exposing configuration panels only to admins. Having direct access to identity and roles within the app makes RBAC logic more flexible and easier to implement.

So in this context, embedding OAuth2 into the app itself simplifies both deployment and internal authorization logic, while also avoiding the need for an extra proxy component that consumes resources and adds operational complexity