question: Why am I not forwarded to the resource after authenticating (OIDC with keycloak)?

[elistia]

Hi,

I have keycloak set up as an OIDC provider and am successfully using it for other OIDC tasks. I am using caddy to reverse proxy a number of systems, but also now to serve some static files (using file_server browse).

I would like to use OIDC to provide a layer of security over the shared files.

I am running caddy as a docker container, and have replaced the standard image with ghcr.io/authcrunch/authcrunch:latest

I seem to have got caddy-security working in that when hitting a protected resource I am forwarded to my keycloak login page. However, on authentication, I am not returned to the resource that I had initially tried to access, but to a caddy-security portal page, which simply gives an option to Sign Out.

My Caddyfile is as follows:

{
        auto_https disable_certs
        order authenticate before respond
        order authorize before basicauth

        debug

        security {
                oauth identity provider keycloak {
                        driver generic
                        realm keycloak
                        client_id {env.KEYCLOAK_CLIENT_ID}
                        client_secret {env.KEYCLOAK_CLIENT_SECRET}
                        scopes openid email
                        base_auth_url https://keycloak.mydomain.com/realms/MyRealm
                        metadata_url https://keycloak.mydomain.com/realms/MyRealm/.well-known/openid-configuration
                }

                authentication portal keycloak_portal {
                        crypto default token lifetime 3600
                        crypto key sign-verify {env.JWT_SHARED_KEY}
                        enable identity provider keycloak
                        cookie domain mydomain.com

                        # unsure if this is required
                        transform user {
                                match realm keycloak
                                action add role authp/user
                        }
                }

                authorization policy mypolicy {
                        set auth url /caddy-security/oauth2/keycloak
                        allow roles *
                        #allow roles authp/user
                        crypto key verify {env.JWT_SHARED_KEY}
                        validate bearer header
                        inject headers with claims
                }
        }
}

*.mydomain.com:443 {
        tls /etc/ssl/certs/my-chain.pem /etc/ssl/certs/key.pem
}

www.mydomain.com:443 {

        route /caddy-security/* {
                authenticate with keycloak_portal
        }

        redir /pub /pub/
        handle_path /pub/* {
                authorize with mypolicy
                root * /srv/www/pub
                file_server browse
        }
}

The ClientID, ClientSecret and JWT key are being set as env variables in docker compose.

I am not really worried about authorization using groups at this stage. As long as a user has successfully authenticated with keycloak then happy to let them in (hence using allow roles *)

When I browse to https://www.mydomain.com/pub I am forwarded to my keycloak login page as expected.

After logging in I am redirected to https://www.mydomain.com/caddy-security/portal

If I then manually navigate back to https://www.mydomain.com/pub I am able to access the contents so things are working. However, users will expect to be redirected to the page they initially tried to access (when sent a link to a file for example).

At what stage is the "redirect to original resource" supposed to happen? I cannot see anything in the debug logs that suggests it is being attempted and failing.
When I am forwarded to keycloak, redirect_url=www.mydomain.com/caddy-security/oauth2/keycloak/authorization-code-callback which I assume is correct?

Should something be kicking in at this point and redirecting the user to /pub?

Appreciate any help - I feel that I am close!

[greenpau]

@elistia , thank you for opening the issue. Did you get a chance to use free ChatGPT and troubleshoot using the skills in this repo? See #498

[greenpau]

Please do troubleshoot, but this is related to the lack of “trusted redirect login” directive.

[greenpau]

Let see if agentic approach arrives at the same advice.

[elistia]

I have used AI to help. Unfortunately it keeps returning to making sure that the redirect_url is set correctly when forwarding to keycloak.

When prompted about trusted redirect login, AI responded with following:

---

Yes, you might need a trusted redirect directive if your authentication portal is bouncing users back to a subdomain or domain that isn't explicitly trusted by caddy-security.

By default, the plugin implements strict security controls to prevent open redirect vulnerabilities (where an attacker uses your login portal to bounce users to a malicious site). If the target URL path or domain in your redirect query parameter is not implicitly allowed, caddy-security will block the automatic hop.

When You Need It

You need to declare trusted redirects if:

• Your OIDC login flow originates from *.mydomain.com but redirects across different subdomains.
• You are passing full absolute URLs in your redirect query strings that do not strictly match the primary host configuration of the authentication portal block.

---

Is this correct? Do I need a trusted redirect login directive even when all routes are to *.mydomain.com?

Do I need to explicitly define a trusted redirect for any route that I add authentication for (i.e. /pub/*)?

[elistia]

Ok, further work with ChatGPT has suggested the following after I told it I was using ghcr.io/authcrunch/authcrunch:latest docker image

---

I think we've found the missing piece.

The ghcr.io/authcrunch/authcrunch:latest image tracks the latest AuthCrunch releases, and recent versions introduced a security change: the portal will no longer honor redirect_url unless you explicitly trust the destination URI. If no trusted redirect rules are configured, the portal intentionally ignores redirect_url and sends the user to the portal landing page instead.

---

so - I have added trust login redirect uri domain suffix mydomain.com path prefix /

This means that I am now being redirected to www.mydomain.com on login, but NOT to the /pub location

I have checked, and the immediate redirect after accessing pub is as follows:

/caddy-security/oauth2/keycloak?redirect_url=https%3A%2F%2Fwww.mydomain.com%2F

so the /pub part does not seem to be being passed in the first place. ChatGPT suggested it might be the fault of the redir /pub /pub/ directive, so I have removed that.

AI has also said:

---

🧠 The smoking gun in your config

This line is now highly suspicious:

authorization policy mypolicy {
set auth url /caddy-security/oauth2/keycloak

In newer AuthCrunch versions, this field is not the correct way to bind redirect tracking anymore.

---

It has suggested removing the set auth url directive entirely, but this stops the forwarding to keycloak (get forwarded to mydomain.com/auth instead)

Sorry - AI is going round in circles now

[greenpau]

Is this correct? Do I need a trusted redirect login directive even when all routes are to *.mydomain.com?

Yes.

Do I need to explicitly define a trusted redirect for any route that I add authentication for (i.e. /pub/*)?

You can do it like this:

caddy-security/assets/config/home.Caddyfile

Lines 214 to 215 in b96087f

	trust logout redirect uri domain partial myfiosgateway.com path suffix /
	trust login redirect uri domain partial myfiosgateway.com path suffix /

This is the skill exerpt.

caddy-security/.codex/skills/configuration-authentication/SKILL.md

Lines 116 to 121 in bd99ff9

	Trusted redirect URI checks support login and logout redirect targets:
	```caddyfile
	trust login redirect uri domain exact example.com path prefix /app
	trust logout redirect uri domain example.com path /
	```

@elistia , thank you for trying the AI. It is helpful, because I will point it to this issue to update the skill.

[greenpau]

🧠 The smoking gun in your config

This line is now highly suspicious:

authorization policy mypolicy {
set auth url /caddy-security/oauth2/keycloak

In newer AuthCrunch versions, this field is not the correct way to bind redirect tracking anymore.

@elistia , how did you prompt it? Did you say the following?

Use the skills in `https://github.com/greenpau/caddy-security/tree/main/.codex/skills`

[elistia]

I did. And it responded with:

---

Yes. I can follow the guidance and workflows from the caddy-security Codex skills in that repository as a reference when helping you configure or troubleshoot caddy-security. The repository recently added skills covering topics like:

Caddyfile router configuration
OAuth provider configuration
SSO application configuration
Authorization policies
HTTP integration guidance
Credentials management
Break/fix troubleshooting workflows
Coding directives for contributions

I can't literally "load" or execute a Codex skill the way the Codex CLI does, but I can:

apply the same configuration patterns,
follow the recommended troubleshooting workflow,
structure answers similarly to the skill,
and adapt the guidance to your specific environment.

If you're working on caddy-security, just tell me what you're trying to do—for example:

configure OAuth/OIDC with Google, GitHub, Authentik, Keycloak, Pocket ID, etc.
protect applications behind Caddy
configure JWT or authorization policies
debug authentication failures
migrate an existing Caddyfile
build Caddy with the greenpau/caddy-security plugin

I'll use the project's guidance and current best practices to walk through it.

---

[elistia]

Current Caddyfile after some AI suggestions:

{
        auto_https disable_certs
        order authenticate before respond
        order authorize before basicauth

        debug

        security {
                oauth identity provider keycloak {
                        driver generic
                        realm keycloak
                        client_id {env.KEYCLOAK_CLIENT_ID}
                        client_secret {env.KEYCLOAK_CLIENT_SECRET}
                        scopes openid email
                        base_auth_url https://keycloak.mydomain.com/realms/MyDomain
                        metadata_url https://keycloak.mydomain.com/realms/MyDomain/.well-known/openid-configuration
                }

                authentication portal keycloak_portal {
                        crypto default token lifetime 3600
                        crypto key sign-verify {env.JWT_SHARED_KEY}
                        enable identity provider keycloak
                        cookie domain mydomain.com

                        trust login redirect uri domain suffix mydomain.com path prefix /

                        transform user {
                                match realm keycloak
                                action add role authp/user
                        }
                }

                authorization policy mypolicy {
                        #tried taking this out but didn't help
                        set auth url /caddy-security/oauth2/keycloak

                        allow roles *
                        crypto key verify {env.JWT_SHARED_KEY}
                        #validate bearer header
                        inject headers with claims
                }
        }
}

www.mydomain.com:443 {

        route /caddy-security/* {
                authenticate with keycloak_portal
        }

        #redir /pub /pub/
        handle /pub/* {
                authorize with mypolicy
                uri strip_prefix /pub           
                root * /srv/www/pub
                file_server browse
        }
}

[elistia]

So I should be using

trust login redirect uri domain partial mydomain.com path suffix /

instead of

trust login redirect uri domain suffix mydomain.com path prefix /

?

Although it does seem to be redirecting now, just to the root rather than to the proper directory (which seems to not be being set in the first place).