Oauth2 redirection Issue

[devopscaxsol]

Description - What happened? *

Hello,

I am following up production guideline. I have configured all in local. i am using env variables for oauth2 as per guideline. when I am trying to hit frontend url it is redirect to oauth2 and after successfull login its thrown 500 ERROR like

192.168.0.154:40296 - 921b846a-6225-44bf-a1dd-8a6900a777d3 - xxxxx [2025/03/03 17:07:58] xxxx GET / "/api/user-info" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" 500 74 0.008

everything configured as define in guideline. Using all official images of sovity. no custom images.

Expected Behavior *

expect success ful login in dataspace portal but stuck in /api/userinfo with 500.

Observed Behavior *

when we authenticated successful we are getting error as above mentioned.

192.168.0.154:40296 - e707cc29-2bbf-4952-9ee3-ecd78aad2324 - xxxx [2025/03/03 17:07:57] [AuthSuccess] Authenticated via OAuth2: Session{email:xxxxx user:017870c3-fe55-4d03-8cf0-aafc1bfaf300 PreferredUsername:xxxxx token:true id_token:true created:2025-03-03 17:07:57.665698935 +0000 UTC m=+2112.211396179 expires:2025-03-03 17:08:57.663814785 +0000 UTC m=+2172.209512030 refresh_token:true groups:[role:offline_access role:default-roles-authority-portal role:uma_authorization role:account:manage-account role:account:manage-account-links role:account:view-profile]}

192.168.0.154:40296 - e707cc29-2bbf-4952-9ee3-ecd78aad2324 - - [2025/03/03 17:07:57] xxxxxx GET - "/oauth2/callback?state=D4O6wXFsiWfBzMWqbMcrpq32wPxMFF0tZ3ZfXFAarBQ%3Ahttps%3A%2F%2Fxxxxx&session_state=3e04dc35-f698-4fcc-83c2-92edfea2074c&iss=https%3A%2F%2Fx%2Frealms%2Fauxxxxthority-portal&code=e7aef32f-7d77-4b1e-9680-120184ee9a58.3e04dc35-f698-4fcc-83c2-92edfea2074c.e9254817-e123-4659-a8bf-b5c59e1c71a5" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" 302 44 0.022

Steps to Reproduce

No response

Context Information

No response

Relevant log output

Screenshots

No response

[tmberthold]

Hello, please check you backend logs, as those logs only show the calls done by the frontend. If locally 500 is happening, there has to be something in the logs in the service which throws them.

[devopscaxsol]

@tmberthold

thanks for response.

below is backend logs of data space portal backend service.

"level":"ERROR","message":"HTTP Request to /api/user-info failed, error id: 71b7da72-1e39-4943-954f-d845f913777f-2","threadName":"executor-thread-31","threadId":81,
"mdc":{"spanId":"f4f4ee949063a6ba","traceId":"d7e681e4e653d365fea643f1454b1d91","sampled":"true"},"ndc":"","hostName":"dsp-backend-7d547ffc84-svk9w","processName":"quarkus-run.jar","processId":1,
"exception":{"refId":1,"exceptionType":"java.lang.IllegalStateException","message":"User with id 344d6174-c17a-4f65-b35b-58978d6fdd7c not found","frames":[{"class":"de.sovity.authorityportal.web.services.UserService","method":"getUserOrThrow","line":35},{"class":"de.sovity.authorityportal.web.services.UserService_ClientProxy","method":"getUserOrThrow"},{"class":"de.sovity.au
thorityportal.web.auth.providers.KeycloakJwtUtils","method":"getUserAndRoles","line":46},{"class":"de.sovity.authorityportal.web.auth.providers.KeycloakJwtUtils_ClientProxy","method":"getUserAndRoles"},{"class":"de.sovity.autho
rityportal.web.auth.LoggedInUserFactory","method":"getLoggedInUser","line":50},{"class":"de.sovity.authorityportal.web.auth.LoggedInUserFactory_ProducerMethod_getLoggedInUser_GRcACa9h6SbBpeKc6N732OmgNe0_Bean","method":"doCreate
"},{"class":"de.sovity.authorityportal.web.auth.LoggedInUserFactory_ProducerMethod_getLoggedInUser_GRcACa9h6SbBpeKc6N732OmgNe0_Bean","method":"create"},

**as per this logs we are able to authenticated but when redirect to backend service from caddy via oauth2 proxy we are getting this.

Ideally DB level migration/ entry for new users must be created. it is not happening right now.**

docker image used by me is https://github.com/sovity/dataspace-portal/releases/tag/v5.0.0

Thanks

[AbdullahMuk]

@devopscaxsol unfortunately this is not sufficient information for us to help you asynchronously at this time.

As indicated by the initial formular that you filed for this discussion, please provide us in details the "Steps to Reproduce". Thank you.

[GaneshDholi]

Auth is fine in Keycloak, but the Dataspace Portal backend cannot find a corresponding user record in its Postgres DB.

• The portal backend expects every authenticated Keycloak user to exist in the Portal DB.
• Normally, a record is auto-provisioned on first login.
• In this setup, provisioning did not happen → so /api/user-info fails.

1. Check if user exists in DB

   select * from users where id = '344d6174-c17a-4f65-b35b-58978d6fdd7c';

→ If no rows: provisioning failed.

Verify configs

Ensure .env values match Keycloak setup:

AUTH_REALM=authority-portal
AUTH_CLIENT_ID=
AUTH_ISSUER_URL=https:///realms/authority-portal
Check Keycloak token contains sub, preferred_username, and email claims.

Quick unblock (manual insert)
Insert the user into the DB manually:

sql
insert into users (id, email, username, created_at)
values (
'344d6174-c17a-4f65-b35b-58978d6fdd7c', -- Keycloak sub claim (UUID)
'your@email.com',
'your-username',
now()
);
Then retry login → /api/user-info should succeed.

[tmberthold]

Thank you for sharing the workaround!

Yes, when a user logs in for the first time with a valid OIDC token, the backend should automatically create a corresponding database entry. If this does not happen, it is usually caused by configuration issues in the environment. Common root causes are:

• the OAuth2 Proxy is not passing the access token to the backend OAUTH2_PROXY_PASS_ACCESS_TOKEN=true is required
• wrong or incomplete quarkus.oidc.auth-server-url / client configuration in the backend
• an incompatible Keycloak version (e.g. see note here in this release: https://github.com/sovity/dataspace-portal/releases/tag/v4.1.5 )
• missing or misconfigured mappers/claims in Keycloak, so the backend cannot identify the user

In such cases, the backend does not recognize the user from the token and therefore skips the provisioning, which explains why the entry had to be added manually in your case.