You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thank you for the excellent work you have done on oidc-provider.
I would like to propose a new option to resolve an issue I have encountered.
You will find all the details below, and I hope I have provided sufficient information.
Description
When the Authorization Server is deployed behind a Reverse Proxy with a path prefix.
I notice problems in the OpenID Connect journey like:
Broken redirection
Cookie path mismatches
Generated URLs in discovery endpoint (/.well-known/openid-configuration) don't include this prefix
We are in a context of Microservice architecture.
We have mounted the OpenID Connect Provider on /oidc of one of the existing service which we will refer to here as “my-service”.
We use a Reverse Proxy with path-based routing to forward the request to the correct service (used for internal routing).
We use Nginx in front of this Reverse Proxy to route from internet.
Our application we will refer to here as "my-app".
Here is a diagram to illustrate:
Client -> Internet (my-app.com) -> Nginx -> Reverse Proxy -> Authorization Server (my-service)
The _interaction cookie is set on path on path /my-service/oidc/interaction/:uid
The _interaction_resume cookie is set on path /my-service/oidc/auth/:uid
How to resolve this
I suggest adding an option to the provider configuration (for example: proxyPathPrefix) that allows specifying the path prefix used by the Reverse Proxy.
const provider = new Provider('https://my-app.com/my-service/oidc', {
proxyPathPrefix: '/my-service', // defaults to undefined
// ... other configuration
});
When configured, the prefix is automatically prepended to the mountPath when generating URLs via the urlFor() method, ensuring all generated URLs correctly include the proxy path prefix.
// oidc-provider/lib/helpers/oidc_context.js
urlFor(name, opt) {
const { originalUrl } = this.ctx.req;
let mountPath = originalUrl?.substring(0, originalUrl?.indexOf(this.ctx.request.url))
|| this.ctx.mountPath // koa-mount
|| this.ctx.req.baseUrl // expressApp.use('/op', provider.callback());
|| ''; // no mount
const proxyPathPrefix = instance(provider).configuration.proxyPathPrefix;
if (proxyPathPrefix) {
mountPath = `${proxyPathPrefix}${mountPath}`;
}
return new URL(provider.pathFor(name, { mountPath, ...opt }), this.ctx.href).href;
}
If you want to check the behavior of this option with my test above.
You need to add the option rewriteUrl to the Fastify server where the OIDC provider is mounted:
const server = Fastify({
logger: true,
trustProxy: true,
rewriteUrl(request) {
/*
* In order to demonstrate the problem and to simplify it
* We don't use Nginx in front of the Fastify server.
* So the host is incorrect because we have to specify the port in the url (for example: http://my-app.com:3001/).
* which also requires us to rewrite the url to the correct one
* /my-service/oidc/auth -> /oidc/auth
*
* Because the path "/my-service" doesn't exist in this service.
*
* This is a workaround to simulate the use of Nginx.
* In real life, we don't need this!
*
* Otherwise, the Nginx configuration would look something like this:
* server {
* listen 127.0.0.1:80;
* server_name my-app.com;
*
* location / {
* proxy_pass http://127.0.0.1:3001;
* }
*
* location /my-service {
* proxy_pass http://127.0.0.1:3001;
* }
* }
*/
console.log("[fastify] rewriteUrl:", request.url);
if (request.url?.startsWith("/my-service")) {
console.log("[fastify] rewriteUrl after:", request.url.slice("/my-service".length));
return request.url.slice("/my-service".length)
}
console.log("[fastify] rewriteUrl after:", request.url || '/');
return request.url || '/'
},
})
What do you think of my proposal? Is it clear and detailed?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, thank you for the excellent work you have done on
oidc-provider.I would like to propose a new option to resolve an issue I have encountered.
You will find all the details below, and I hope I have provided sufficient information.
Description
When the Authorization Server is deployed behind a Reverse Proxy with a path prefix.
I notice problems in the OpenID Connect journey like:
/.well-known/openid-configuration) don't include this prefixWe are in a context of Microservice architecture.
We have mounted the OpenID Connect Provider on
/oidcof one of the existing service which we will refer to here as “my-service”.We use a Reverse Proxy with path-based routing to forward the request to the correct service (used for internal routing).
We use Nginx in front of this Reverse Proxy to route from internet.
Our application we will refer to here as "my-app".
Here is a diagram to illustrate:
Client -> Internet (my-app.com) -> Nginx -> Reverse Proxy -> Authorization Server (my-service)
In summary:
/my-servicebefore forwarding requests to the service (to "my-service")/oidc/oidc, missing the/my-serviceprefixSteps to reproduce
Firstly, I update the
/etc/hostsfile to add the line:127.0.0.1 my-app.comSecondly, I wrote a test to illustrate this (without using Nginx to simplify), it is composed of two services:
(Below you will find the source code for these two services)
Finally, you have to run the two services and using one of these URL to test and observe the issue:
(I use https://oidcdebugger.com for the redirect URI because it is publicly available on the internet)
You will see that:
_interactionand_interaction_resumecookies are set on incorrect path (missing "/my-service")Reverse proxy
Dependencies: fastify v5.6.1, @fastify/http-proxy v11.3.0
OIDC Provider
Dependencies: fastify v5.6.1, @fastify/middie v9.0.3, oidc-provider v9.5.2
Expected Behavior
_interactioncookie is set on path on path /my-service/oidc/interaction/:uid_interaction_resumecookie is set on path /my-service/oidc/auth/:uidHow to resolve this
I suggest adding an option to the provider configuration (for example:
proxyPathPrefix) that allows specifying the path prefix used by the Reverse Proxy.When configured, the prefix is automatically prepended to the
mountPathwhen generating URLs via theurlFor()method, ensuring all generated URLs correctly include the proxy path prefix.If you want to check the behavior of this option with my test above.
You need to add the option
rewriteUrlto the Fastify server where the OIDC provider is mounted:What do you think of my proposal? Is it clear and detailed?
Beta Was this translation helpful? Give feedback.
All reactions