Switch authentication from current OAuth to use Keycloak

[autumnfound]

Within the Eclipse Foundation, we are in the process of slowly deprecating the usage of the OAuth client provided through the Drupal website and are switching to Keycloak for OIDC services. We will want to change over to use Keycloak for this service, and align with the upstream API change to consume the new authentication source.

For more info, see https://gitlab.eclipse.org/eclipsefdn/it/api/eclipse-openvsx-api/-/issues/38

[autumnfound]

Hi @amvanbaren! We have an internal objective to move this to not use Drupal OAuth by end of June. Is this something that can be accomplished in that time period? What is the best time for us to work on this together. I've done what should be the work on the EF API side of it, but it is untested with the binding API, so I should be able to jump on this whenever you are ready outside the week of June 16th.

[amvanbaren]

Ok, do we need to make changes in the EclipseService?

[autumnfound]

Ok, do we need to make changes in the EclipseService?

Among other things, probably yes. I suspect the class that needs to change most is the TokenService as that sources oauth2 tokens from accounts.eclipse.org, which will need to be switched to auth.eclipse.org. We'll likely want configuration for the base URL, realm name, along with the normal creds so we can swap between auth and auth-staging between environments

[autumnfound]

@amvanbaren how does the time line look on this? Let me know if you need a credential to test locally, as we should be able to get staging on our side running with Keycloak for you to do some real testing.

[amvanbaren]

Ok, do we need to make changes in the EclipseService?

Among other things, probably yes. I suspect the class that needs to change most is the TokenService as that sources oauth2 tokens from accounts.eclipse.org, which will need to be switched to auth.eclipse.org. We'll likely want configuration for the base URL, realm name, along with the normal creds so we can swap between auth and auth-staging between environments

It uses the spring.security.oauth2.provider.eclipse.token-uri from application.yml

openvsx/server/src/main/java/org/eclipse/openvsx/eclipse/TokenService.java

Lines 112 to 118 in 3923d25

	var reg = Optional.ofNullable(clientRegistrationRepository).map(repo -> repo.findByRegistrationId("eclipse")).orElse(null);
	if(reg == null) {
	logger.error("Eclipse client not registered");
	return null;
	}
	var tokenUri = reg.getProviderDetails().getTokenUri();

@autumnfound You can make the changes in https://github.com/EclipseFdn/open-vsx.org/blob/main/configuration/application.yml and test it.

[chrisguindon]

@amvanbaren Can you please verify that everything is working correctly on the Open VSX application, rather than asking @autumnfound?

While we're responsible for the authentication server, we need support from the application developer to ensure it’s properly integrated and functioning as expected.

[amvanbaren]

@chrisguindon I'm looking forward to a PR with the new spring.security.oauth2.client.registration.eclipse configuration.

[autumnfound]

On staging.open-vsx.org, I got the following error when attempting to load my profile:

Error

Request for retrieving user profile failed: 403 Forbidden: [no body]

So it looks like it's at least retrieving credentials, but they aren't being accepted on staging. Does staging.open-vsx target api-staging still, or was it reverted to point at production? I'm pretty sure at some point we had switched it, but it would explain the error we're seeing.

[amvanbaren]

https://github.com/EclipseFdn/open-vsx.org/blob/ef028976583acbf747fe2be6c497d769b8924ad6/configuration/application.yml#L53-L63

[amvanbaren]

2025-06-09T19:39:39.781Z ERROR [openvsx-server,506e688f7a788c0ebb4f6f6c55773107,f87e4dd3e0aed40f] 1 --- [openvsx-server] [qtp1455940305-28] [506e688f7a788c0ebb4f6f6c55773107-f87e4dd3e0aed40f] o.e.openvsx.eclipse.EclipseService       : Get request failed with URL: https://api.eclipse.org/openvsx/profile

org.springframework.web.client.HttpClientErrorException$Forbidden: 403 Forbidden: [no body]
	at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:109)
	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:183)
	at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:137)
	at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
	at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:942)
	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:891)
	at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:730)
	at org.eclipse.openvsx.eclipse.EclipseService.getUserProfile(EclipseService.java:259)

[autumnfound]

@amvanbaren yeah, I had seen a 403 from the service about the profile and figured it was that endpoint. I grabbed the client + secret used by the open-vsx spring app and tested that call through a REST client, and was able to confirm the client can access that endpoint manually. At this point, I can confirm it's something wrong in the open-vsx.org spring app that isn't communicating with the EF API properly.

Also RE the configs, I meant this value https://github.com/EclipseFdn/open-vsx.org/blob/ef028976583acbf747fe2be6c497d769b8924ad6/configuration/application.yml#L166. From what I understand, this had been set to hit api-staging on staging.open-vsx.org via the server configs, which is the correct setup. If that is hitting api.eclipse.org instead, then this error is caused by that, as it uses a different auth server.

[autumnfound]

@amvanbaren I've done some testing, and it looks like I've gotten the server running with Keycloak fully on staging! I worked with @heurtematte to get the internal application configurations updated with the staging values. In the future, we won't need to do pushes to the open-vsx.org site configurations to link to production any more!

I've done testing to load the user + check the publisher agreement, and it seems to work. Are there any functions otherwise that you would need to test? Once we validate that everything still works, we can plan a time to do the production update and close this out!