🚀 Feature: Different base url for openid configuration #74

New Issue

OVERLORD · 2025-10-07T00:00:40+03:00

OVERLORD commented

2025-10-07 00:00:40 +03:00

Originally created by @DerSteph on GitHub.

Feature description

Add possibility to have different base urls for the openid configuration endpoints via env variables, at least for those who are called by the OIDC client.

These are (at least according to chatgpt based on the openid-configuration)

token_endpoint
userinfo_endpoint
introspection_endpoint
jwks_uri

For those, either have one env variable INTERNAL_APP_URL or for each one an own env variable.

The url would then only be used, when INTERNAL_APP_URL is defined, otherwise it would still use APP_URL as default.

If you want, i can also provide an pull request with my changes.

Pitch

Im currently using pocket-id in my homelab in a small kubernetes cluster and im using mDNS annoucements via a customized controller to publish my dns records in my local network. Also im using traefik-oidc-auth as oidc client.

In general this mean my pocket-id instance has pocket-id.local as domain in my home network.

When im trying to use pocket-id for adding authentication for one of my services, i cannot continue after logging in successfully, as i get Failed to exchange auth code.

When investigating, why its not working, i found that traefik-oidc-auth cannot access pocket-id.local, as it cannot resolve the mDNS domain in the pod itself.

By digging in a bit deeper, i found out that pocket-id is providing the .well-known/openid-configuration which is used by traefik-oidc-auth to find out which urls have to be called.

{ //... "token_endpoint": "https://pocket-id.local/api/oidc/token", "userinfo_endpoint": "https://pocket-id.local/api/oidc/userinfo" }

Ive then changed the source code of pocket-id, so that can define via env variables custom base urls for some of the endpoints and then my login workflow worked as expected.

APP_URL: https://pocket-id.local INTROSPECTION_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411 JWKS_URI: http://pocket-id.pocket-id-system.svc.cluster.local:1411 TOKEN_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411 USERINFO_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411

Ive only changed the once, where the connection between pocketid and traefik-oicd-auth is needed.
{ "authorization_endpoint": "https://pocket-id.local/authorize", "device_authorization_endpoint": "https://pocket-id.local/api/oidc/device/authorize", "end_session_endpoint": "https://pocket-id.local/api/oidc/end-session", "introspection_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/introspect", "issuer": "https://pocket-id.local", "jwks_uri": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/.well-known/jwks.json", "token_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/token", "userinfo_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/userinfo" }

So there were then two options: Either change the logic in pocket-id or in traefik-oidc-auth. Ive changed it then here, as it seemed more easier.

Perhaps for some people who have kind the same setup as me or just want to have the traffic internally handled, this would be a nice improvement 👍

Originally created by @DerSteph on GitHub. ### Feature description Add possibility to have different base urls for the openid configuration endpoints via env variables, at least for those who are called by the OIDC client. These are (at least according to chatgpt based on the openid-configuration) - token_endpoint - userinfo_endpoint - introspection_endpoint - jwks_uri For those, either have one env variable INTERNAL_APP_URL or for each one an own env variable. The url would then only be used, when INTERNAL_APP_URL is defined, otherwise it would still use APP_URL as default. If you want, i can also provide an pull request with my changes. ### Pitch Im currently using pocket-id in my homelab in a small kubernetes cluster and im using mDNS annoucements via a customized controller to publish my dns records in my local network. Also im using traefik-oidc-auth as oidc client. In general this mean my pocket-id instance has pocket-id.local as domain in my home network. When im trying to use pocket-id for adding authentication for one of my services, i cannot continue after logging in successfully, as i get `Failed to exchange auth code`. <img width="421" height="145" alt="Image" src="https://github.com/user-attachments/assets/2cd310a3-0d30-4d7a-8302-8261357bd0a4" /> When investigating, why its not working, i found that traefik-oidc-auth cannot access pocket-id.local, as it cannot resolve the mDNS domain in the pod itself. <img width="1873" height="111" alt="Image" src="https://github.com/user-attachments/assets/e70aab2a-c417-4b84-87e4-f59e8a2b80e0" /> By digging in a bit deeper, i found out that pocket-id is providing the `.well-known/openid-configuration` which is used by traefik-oidc-auth to find out which urls have to be called. ` { //... "token_endpoint": "https://pocket-id.local/api/oidc/token", "userinfo_endpoint": "https://pocket-id.local/api/oidc/userinfo" } ` Ive then changed the source code of pocket-id, so that can define via env variables custom base urls for some of the endpoints and then my login workflow worked as expected. ` APP_URL: https://pocket-id.local INTROSPECTION_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411 JWKS_URI: http://pocket-id.pocket-id-system.svc.cluster.local:1411 TOKEN_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411 USERINFO_ENDPOINT: http://pocket-id.pocket-id-system.svc.cluster.local:1411 ` Ive only changed the once, where the connection between pocketid and traefik-oicd-auth is needed. ` { "authorization_endpoint": "https://pocket-id.local/authorize", "device_authorization_endpoint": "https://pocket-id.local/api/oidc/device/authorize", "end_session_endpoint": "https://pocket-id.local/api/oidc/end-session", "introspection_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/introspect", "issuer": "https://pocket-id.local", "jwks_uri": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/.well-known/jwks.json", "token_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/token", "userinfo_endpoint": "http://pocket-id.pocket-id-system.svc.cluster.local:1411/api/oidc/userinfo" } ` So there were then two options: Either change the logic in pocket-id or in traefik-oidc-auth. Ive changed it then here, as it seemed more easier. Perhaps for some people who have kind the same setup as me or just want to have the traffic internally handled, this would be a nice improvement 👍

OVERLORD closed this issue

2025-10-07 00:00:41 +03:00

OVERLORD commented

2025-10-07 00:00:43 +03:00

@ItalyPaleAle commented on GitHub:

I understand the use problem you're trying to solve but I'm really not sure that changing it on Pocket ID would be the right approach...

The problem is that this fundamentally breaks how OpenID Connect works.

Tokens that are issued by Pocket ID include an access token and an ID token. Pocket ID issues these with the value of iss set to the AppURL: 23abe06ab4/backend/internal/service/jwt_service.go (L253-L257)

The issuer claim is important because clients can use that to identify the issuer, and should be able to make calls to <issuer>/.well-known/openid-configuration

This is required by the OpenID Connect spec, section 4 (and see also 4.1 for more clarification):

OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer.

In your case, I would recommend investigating other ways to make Pocket ID available on an endpoint that can be reachable by other apps too, and not just your clients..

@ItalyPaleAle commented on GitHub: I understand the use problem you're trying to solve but I'm really not sure that changing it on Pocket ID would be the right approach... The problem is that this fundamentally breaks how OpenID Connect works. Tokens that are issued by Pocket ID include an access token and an ID token. Pocket ID issues these with the value of `iss` set to the `AppURL`: https://github.dev/DerSteph/pocket-id/blob/23abe06ab423ba9f4e970bdc0018a31be493f52b/backend/internal/service/jwt_service.go#L253-L257 The issuer claim is important because clients can use that to identify the issuer, and should be able to make calls to `<issuer>/.well-known/openid-configuration` This is required by the [OpenID Connect spec, section 4](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) (and see also 4.1 for more clarification): > OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer. In your case, I would recommend investigating other ways to make Pocket ID available on an endpoint that can be reachable by other apps too, and not just your clients..

OVERLORD commented

2025-10-07 00:00:43 +03:00

@stonith404 commented on GitHub:

Yeah I didn't find anything against this as well. But wouldn't it make more sense to just add a single INTERNAL_APP_URL variable instead of one for every single endpoint? I don't really see a use-case where you need different URLs for each endpoint.

@stonith404 commented on GitHub: Yeah I didn't find anything against this as well. But wouldn't it make more sense to just add a single INTERNAL_APP_URL variable instead of one for every single endpoint? I don't really see a use-case where you need different URLs for each endpoint.

OVERLORD commented

2025-10-07 00:00:44 +03:00

@kmendell commented on GitHub:

I agree with that yeah there only should be one INTERNAL_APP_URL

@kmendell commented on GitHub: I agree with that yeah there only should be one `INTERNAL_APP_URL`

OVERLORD commented

2025-10-07 00:00:44 +03:00

@DerSteph commented on GitHub:

Yes, i can shortly change it to one env variable ^^

@DerSteph commented on GitHub: Yes, i can shortly change it to one env variable ^^

OVERLORD commented

2025-10-07 00:00:45 +03:00

@kmendell commented on GitHub:

I read over the Oauth2 RFC again cause i for sure thought this went aggainst the Spec, but to my surprise it doesnt, the only requirements for the endpoints is they must be behind TLS.

@stonith404 Correct me if im wrong on that, but thats how i took it.

@kmendell commented on GitHub: I read over the Oauth2 RFC again cause i for sure thought this went aggainst the Spec, but to my surprise it doesnt, the only requirements for the endpoints is they must be behind TLS. @stonith404 Correct me if im wrong on that, but thats how i took it.

OVERLORD commented

2025-10-07 00:00:47 +03:00

@kmendell commented on GitHub:

The issuer would still be the public facing url (APP_URL). that is not being touched in the well-known controller or at all rather it stays at APP_URL. So issuing tokens would not be an issue as the end-user still is accessing over the APP_URL, this is only for exchnaging tokens and grabbing teh data from the urls. While the OIDC spec implies a single base URL for everything, it doesn't explicitly forbid the endpoints within the discovery document from having a different base URL than the issuer itself. So this doesnt go against the spec and doesnt harm anything else in the oidc process based on that. (that being said i do not have an environment to fully test this).

@kmendell commented on GitHub: The issuer would still be the public facing url (APP_URL). that is not being touched in the well-known controller or at all rather it stays at APP_URL. So issuing tokens would not be an issue as the end-user still is accessing over the APP_URL, this is only for exchnaging tokens and grabbing teh data from the urls. While the OIDC spec **implies** a single base URL for everything, it doesn't explicitly forbid the endpoints within the discovery document from having a different base URL than the issuer itself. So this doesnt go against the spec and doesnt harm anything else in the oidc process based on that. (that being said i do not have an environment to fully test this).

OVERLORD commented

2025-10-07 00:00:47 +03:00

@ItalyPaleAle commented on GitHub:

@kmendell you're right, but in the broader picture ...

@DerSteph 's problem is that Pocket ID is running at https://pocket-id.local, and that's the value of the iss claim too.
Per the OIDC specs, OIDC clients expect to be able to retrieve the configuration document at https://pocket-id.local/.well-known/openid-configuration

While we can tweak the contents of the document to make clients able to retrieve the JWKS and other things, they will still be unable to fetch https://pocket-id.local/.well-known/openid-configuration

My recommendation would be to find a way to either install Pocket ID at an endpoint that's reachable by the clients, or make pocket-id.local routable to them.

@ItalyPaleAle commented on GitHub: @kmendell you're right, but in the broader picture ... @DerSteph 's problem is that Pocket ID is running at `https://pocket-id.local`, and that's the value of the `iss` claim too. Per the OIDC specs, OIDC clients expect to be able to retrieve the configuration document at `https://pocket-id.local/.well-known/openid-configuration` While we can tweak the contents of the document to make clients able to retrieve the JWKS and other things, they will still be unable to fetch `https://pocket-id.local/.well-known/openid-configuration` My recommendation would be to find a way to either install Pocket ID at an endpoint that's reachable by the clients, or make `pocket-id.local` routable to them.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#74