UI is trying to use keycloak as openid provider inspite of configuration to not do that

Hi, I am building and running apicurio-registry using the following commands:

<git-cloned-location>/apicurio-registry ./mvnw clean package -DskipTests 
<git-cloned-location>/apicurio-registry ./mvnw quarkus:dev 

with the app application properties as follows:

# Okta TEST
quarkus.oidc.auth-server-url=https://dev-71378222.okta.com/oauth2/default
registry.auth.token.endpoint=https://dev-71378222.okta.com/oauth2/default/v1/token
quarkus.oidc.client-id=<Client-Id>
registry.auth.client-secret=<Client-Secret>
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

quarkus.oidc.authentication.redirect-path=/callback
quarkus.oidc.authentication.restore-path-after-redirect=true

As you can see I am not using keycloak but OKTA. But the UI code tries to use keycloak as can be seen from the code here: https://github.com/Apicurio/apicurio-registry/blob/637b504cd06f39f1e96c91a78429f92ecc14bfc0/ui/src/services/config/config.service.ts#L140

How can I use OKTA and not KeyCloak as OpenID Connect Provider?

thanks

[RoopGuron]

@EricWittmann For some food for thought, you could take a look at how PassportJS is being utilized by other UI apps like backstage.io for instance.

[carlesarnal]

Hi @RoopGuron,

your understanding is correct. As Eric’s says, right now the UI is using keycloakjs for the authentication so it’s not possible to use anything else but Keycloak. That said, it’s on our backlog to address that so users are able to use any other OIDC provider.

In response to your last comment, Quarkus has a nice set of capabilities in the security area. They’re not bundled as a single library but as a set of quarkus extensions. You have a full list here.

Thanks for your comments.