dexidp
Add support for differing internal vs. public URLs.
This is helpful with keeping token management traffic purely internal in Kubernetes while still sending back a public-facing link for auth and callbacks.
@coderanger Can you elaborate on the use case for this and how it works? As far as I was aware, the issuer URL should match the endpoint that the user hits at all times as part of the OIDC spec, is this not the case? Is there precedence for this being done elsewhere?
The spec does say that and it makes sense when the issuer is Google, but when trying to set things up for an internal-only service it's nice for internal-only traffic like /tokens to go via the Service, it's not zigzagging all the way out to my external ingress layer. This helps with both availability planning (fewer things in the path between the two services) and latency. But at the same time, the user-facing bits need to have non-cluster hostnames for the OAuth redirection dance.
@coderanger I can see why this is potentially useful, but I'd like to get more context about what the spec says about such implementation, so if you could quote or point us to the relevant section of the spec, that would be great. Thanks!
As I read through the spec to try and answer that question, I guess actually the spec never specifically states that the authentication endpoint has to be "under" the issuer URL. In fact while the issuer ID needs to be a valid URI, it has no actual connection to the network address of the IdP or any of the endpoints. https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery makes this explicit for Issuer Discovery, but the only specific requirement on authorization endpoints is that they use TLS (https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint).
Thanks for those links and doing the research. I think you're right, this doesn't break the spec.
It does raise the question to me though, can you not manually configure the clients? Since discovery is an optional implementation, your clients should be able to manually configure the token, key and userinfo endpoints right? Does this maybe break the serve mux that Dex has built in 🤔
I guess this is only useful in scenarios where all clients in your configuration can access the internal endpoints? Eg, you couldn't use something like a command line login for users with this?
I think it would be good to update the description of the PR to explain in a bit more detail the motivation and usage of this change, plus we should ideally update the docs to explain the new feature
We are trying to solve similar problem, where this PR can help. I will try to explain our use case, so it is more clear, why we need this.
We are developing application (consisting of several services), where we need authentication. We decided, that we will only support OIDC to make implementation more simple.
There are several situations, where we can not use customer-provided OIDC (customers which does not have OIDC or during development), so we would like to include integrated OIDC (we are mainly considering dex).
Our application will provide multiple deployment options - k8s (for production use), all-in-one docker image (all services in one container - for simple application evaluation) and docker compose based (used by majority of our developers and some automated tests).
Problem is that OIDC must be accessible from internal services and from user browser.
We can currently achieve this in k8s (internal services can use public endpoint) and all-in-one image (everything is localhost), but we have problem with docker compose.
OIDC must be accessible in docker compose network (using service name DNS name) and in user browser (we can not use internal docker compose network, so we need to use localhost and exposed port).
This is not possible to achieve using single issuer URL. It is possible to workaround most of problems using OIDC client configuration, but we can not influence URLs generated by dex itself (e.g. /callback URL), which are concatenated with issuer URL. And we need issuer URL usable for internal communication (we are using Spring Security client, and we can not change it there).
Thus we will us this feature to generate different URLs for external uses (from browser).
Never-mind - we were able to achieve required behavior only with Spring Security configuration - it was incorrectly documented, so some reverse engineering showed possible approach.
This is specifically for the case of all clients are internal but the IdP isn’t
This is exactly our situation. Could this be reconsidered?
