OpenID Connect Authenticator extention - Returns incorrect redirect link that contains ":80"

Hello, community,

I am writing to report an issue that I noticed while using the latest XWiki docker image “xwiki:lts-mysql-tomcat” version “XWiki 14.10.6” in combination with the “OpenID Connect Authenticator 1.34.4” extension, which I successfully configured to work with AzureAD OpenID service.

The problem I encountered is related to the last redirect address returned from the OpenID extension after the user has been successfully authorized. The link contains “:80” at the end, for example, the original XWiki link is “” and after successful authorization, it returns “”.

This issue causes problems for users as the link is not functional since it starts with “https://” and the “:80” added at the end. However, if I manually remove “:80” from the link, then it works perfectly fine.

I want to ask the XWiki community if anyone else has encountered this issue or if they have any suggestions on how to solve it. I would greatly appreciate any help or guidance on how to fix this problem.

During my research, I noticed this similar issue reported on the last post " OpenID Connect login problem - #10 by Peter but unfortunately there are no images or any information on how this has been resolved.

Thank you in advance for your attention and assistance.

Sounds like a problem with how XWiki is configured, you might want to take a look at the main wiki descriptor (https://<yourhost>/bin/view/XWiki/XWikiServerXwiki) and make sure you have the right information in it, especially the SECURE (http or https), PORT and ALIAS (the host).

Could you put the following content in a wiki page and see what URL you get:


That’s what the OIDC authenticator uses to produce the base callback URL sent to the provider.

Hello Thomas,

I’ve added your suggested content to a page of my xwiki setup and returned back the correct https://wiki.myhost:443/

div id=“xwikicontent” class=“c01-xs-12”> == $0

    < span class="wikiexternallink">
        <a class="wikimodel-freestanding" href="">
			<span class="wikigeneratedlinkcontent"></span>
<div class="box floatinginfobox"> == $0

But as I’ve mentioned initially this seems to be an issue with the “OpenID Connect Authenticator 1.34.4” extension.

In my case when I reach my xwiki page the “OpenID Connect Authenticator” returns back the following Microsoft Authentication page<Directory (tenant) ID>/oauth2/v2.0/authorize?scope=openid+profile+email&claims=%7B%22id_token%22%3A%7B%22xwiki_instance_id%22%3Anull%7D%2C%22userinfo%22%3A%7B%22xwiki_user_accessibility%22%3Anull%2C%22xwiki_user_displayHiddenDocuments%22%3Anull%2C%22xwiki_user_editor%22%3Anull%2C%22xwiki_user_usertype%22%3Anull%2C%22xwiki_user_company%22%3Anull%7D%7D&response_type=code&<Application (client) ID>&sso_reload=true

and after the user has been successfully authorized. it returns “”. and that link contains “:80”

I’ve made the following workaround in order to bypass this issue and have the xwiki works with this incorrect link “” and not to have manually removed “:80” from that url, by using an nginx-proxy-manager with the following configuration, but after I’ve issued a certificate for my “" I’ve changed the port on its docker-compose.yml configuration to have both port 80 and 443 to point to 443

version: ‘3’
image: ‘jc21/nginx-proxy-manager:latest’
- ‘80:443’
- ‘443:443’
- ‘81:81’
- ‘8181:80’

So, is there a way to check the “OpenID Connect Authenticator 1.34.4” extension operation, since in this similar issue reported in the last post " OpenID Connect login problem - #10 by Peter it has the same issue with the “OpenID Connect Authenticator" extension, and as he mentioned he had to change something on this extension code to make it work in the proper way, by returning back the correct xwiki URL without the addition of “:80” in

Thank you again for your attention and assistance.

It’s not very clear what was the modification made, as it seems to be in a missing image.

After a full, successful OIDC process, you are supposed to be redirected where you were when the auth started. To do that it remember and the store initial source URL to redirect to it and this depends a lot on a proper setup of the HTTP proxy you have in front of XWiki.

The following code can help understand exactly what information the HTTP proxy transmit about the source URL:

{{groovy wiki="false"}}
  println 'HTTP header "forwarded": ' + xcontext.request.getHeader('forwarded')
  println 'HTTP header "x-forwarded-host": ' + org.xwiki.container.servlet.HttpServletUtils.getFirstHeaderValue(xcontext.request, 'x-forwarded-host')
  println 'Application server port: ' + xcontext.request.getServerPort()

  println org.xwiki.container.servlet.HttpServletUtils.getSourceBaseURL(xcontext.request)

Hello Thomas,

Thank you for pointing me in the right direction in order to resolve this issue.

I’ve added your suggested code to a page of my xwiki setup and returned back the following

HTTP header “forwarded”: null
HTTP header “x-forwarded-host”: null
Application server port: 80

So I’ve managed to resolve this issue by reconfiguring the nginx-proxy-manager accordingly in order to set up the HTTP header “x-forwarded-host” and the "Application server port

I’ve changed back the ports on its docker-compose.yml configuration to the default values

image: ‘jc21/nginx-proxy-manager:latest’
- ‘80:80’
- ‘443:443’
- ‘81:81’

I have the following NPM Proxy Host setup for my wiki server:


Domain Name:
Forward Hostname/IP:
Forward Port:80


SSL Certificate:
Force SSL (Enabled)


location / {
proxy_pass $forward_scheme://$server:$port;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host:443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;

So, now I get the following results and the OIDC extension works fine without any issue with AzureAD OpenID service.

HTTP header “forwarded”: null
HTTP header “x-forwarded-host”:
Application server port: 443

Here are the changes I had already made in the xwiki.cfg and and can successfully authenticate using the OpenID with AzureAD



oidc.xwikiprovider=<my Azure xwiki app Directory (tenant) ID>/oauth2
oidc.endpoint.authorization=<my Azure xwiki app Directory (tenant) ID>/oauth2/v2.0/authorize
oidc.endpoint.token=<my Azure xwiki app Directory (tenant) ID>/oauth2/v2.0/token
oidc.endpoint.authorization=<my Azure xwiki app Directory (tenant) ID>/oauth2/v2.0/authorize



oidc.clientid=<my Azure xwiki app Application (client) ID>
oidc.secret=<my Azure xwiki app Application (secret) ID>

The only remaining question is if somehow we should configure also the “HTTP header “forwarded”: null” to something else or not and if this will cause any issues on xwiki normal operation.

Best regards

Basically, you only need to have one of those 3 things correct (getSourceBaseURL try each one in the order I indicated) so “x-forwarded-host” was enough. It’s just that ‘forwarded’ is the only standard one from HTTP specification point of view (but “x-forwarded-host” is so common that it can almost be seen as a do facto standard from before the introduction of ‘forwarded’).