oidc: failed to decode provider discovery object

[mitchplze]

Description
I am trying to setup OIDC authentication on a new install of Filebrowser, to connect to Pocket ID.

Expected behaviour
Expected an OIDC login flow to kick-off

What is happening instead?
Container does not start and throws:

[FATAL] Error validating OIDC auth: url 'https://id.mydomain.com/authorize' failed to create OIDC provider: oidc: failed to decode provider discovery object: expected Content-Type = application/json, got "text/html; charset=utf-8": invalid character '<' looking for beginning of value

Additional context
I have never had an issue with the Pocket ID /authorize endpoint on any other applications. I have approximately 20+ other apps configured out of the box with Pocket ID / OIDC.

How to reproduce?

• Deploy Pocket ID
• Create new OIDC client
• Copy ID, secret values
• Provide in config to filebrowser

Files

data/config.yaml:

server:
  sources:
    - path: /mnt
auth:
  methods:
    oidc:
      enabled: true
      clientId: "redacted"
      clientSecret: "redacted"
      issuerUrl: "https://id.mydomain.com/authorize"
      scopes: "email openid profile"
      userIdentifier: "username"
      disableVerifyTLS: false
      createUser: true

[gtsteffaniak]

The issuer url should return json and it looks like an html response, perhaps from a proxy?

got "text/html; charset=utf-8": invalid character '<' looking for beginning of value

It could be, just guessing , a missing slash at the end

Try https://id.mydomain.com/authorize/ , it could be that the oidc module I use doesn't follow redirects if it's getting redirected.

[mitchplze]

Adding the slash does not seem to make a difference.

A simple curl -v https://id.example.com/authorize returns the same output on my laptop and inside the FB container (after adding curl).

My OIDC container is definitely behind a simple proxy (caddy and I think also cloudflare) for HTTPS amongst other stuff. This has not ever presented a problem before though with any other OIDC connections.

Anything else I can do to help troubleshoot this one? FBQ is a really cool project!

BTW: At the moment I can utilize a oauth2-proxy sidecar and your proxy header SSO method to achieve loosely the same result, but with more steps and containers.

[gtsteffaniak]

ok interesting -- so the endpoint returns json when you curl from inside the FB container?

Just looking the oidc go module it uses the actual full URL is different.

What happens when you curl:

https://id.example.com/authorize/.well-known/openid-configuration

I bet you need to update your proxy to expose that path fully.

[mitchplze]

It doesn't look like JSON, no, but it does show up the same on any system, so it doesn't seem to me like a proxy issue. But I could be totally wrong. Attached it below.

My Caddy reverse proxy is open and not handling any URLs specially.

Here is what the config screen for Pocket ID shows. I tried using the OIDC Discovery URL in FB, same problem.

(You also prefixed /authorize in your ask, which I also tried for fun - no joy.)

---

Caddyfile reverse proxy function:

(reverse-proxy) {
	# [0] subdomain [1] top domain [2] destination and port 
	@{args[0]} host {args[0]}.{args[1]}
	handle @{args[0]} {
		reverse_proxy {args[2]}
	}
}

---

Caddyfile line for Filebrowser: (this format works great with countless other apps)

import reverse-proxy fb domain.com 10.123.123.123:1234 # Filebrowserq

In fact, Pocket ID line looks like this (different server):

import reverse-proxy id example.com 1.2.3.4:1234 # Pocket-ID

---

Curl output to my Pocket ID instance from laptop:

root@localhost ~ % curl -v https://id.example.com/authorize
* Host id.example.com:443 was resolved.
* IPv6: redacted
* IPv4: redacted
*   Trying redacted...
* Connected to id.example.com (redacted) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=example.com
*  start date: redacted
*  expire date: redacted
*  subjectAltName: host "id.example.com" matched cert's "*.example.com"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://id.example.com/authorize
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: id.example.com]
* [HTTP/2] [1] [:path: /authorize]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /authorize HTTP/2
> Host: id.example.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< date: Fri, 20 Jun 2025 22:04:55 GMT
< content-type: text/html; charset=utf-8
< cf-ray: redacted-SEA
< alt-svc: h3=":443"; ma=86400
< cache-control: public, max-age=86400
< last-modified: Thu, 19 Jun 2025 18:36:15 GMT
< vary: Accept-Encoding
< via: 1.1 Caddy
< cf-cache-status: DYNAMIC
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\redacted"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< strict-transport-security: max-age=15552000; includeSubDomains
< server: cloudflare
< server-timing: cfL4;desc="?proto=TCP&rtt=9923&min_rtt=9258&rtt_var=2422&sent=8&recv=12&lost=0&retrans=0&sent_bytes=2914&recv_bytes=578&delivery_rate=298310&cwnd=91&unsent_bytes=0&cid=02d11056bf67615e&ts=813&x=0"
< 
<!doctype html>
<html lang="%lang%">
	<head>
		<meta charset="utf-8" />
		<link rel="icon" href="/api/application-configuration/favicon" />
		<meta name="viewport" content="width=device-width, initial-scale=1" />
		<meta name="robots" content="noindex" />
		
		<link rel="modulepreload" href="/_app/immutable/entry/start.DDfv3gn-.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/h1yLYwNP.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/BWOeZN_s.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/CYgJF_JY.js">
		<link rel="modulepreload" href="/_app/immutable/entry/app.CuaaxZlc.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/Dp1pzeXC.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/BQi9nghC.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/DRr2agmC.js">
		<link rel="modulepreload" href="/_app/immutable/chunks/CRmzXeKy.js">
	</head>
	<body data-sveltekit-preload-data="hover">
		<div style="display: contents">
			<script>
				{
					__sveltekit_1vzkeo = {
						base: ""
					};

					const element = document.currentScript.parentElement;

					Promise.all([
						import("/_app/immutable/entry/start.DDfv3gn-.js"),
						import("/_app/immutable/entry/app.CuaaxZlc.js")
					]).then(([kit, app]) => {
						kit.start(app, element);
					});
				}
			</script>
		</div>
	<script>(function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'952e90872da257bc',t:'MTc1MDQ1NzA5NS4wMDAwMDA='};var a=document.createElement('script');a.nonce='';a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();</script></body>
</html>
* Connection #0 to host id.example.com left intact

[mitchplze]

Different result with the /.well.known url. Seems to get JSON at the end. (note: does not have /authorize)

root@localhost ~ % curl -v https://id.example.com/.well-known/openid-configuration
* Host id.example.com:443 was resolved.
* IPv6: redacted
* IPv4: redacted
*   Trying redacted
* Connected to id.example.com (redacted) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=example.com
*  start date: May 25 13:07:17 2025 GMT
*  expire date: Aug 23 14:05:42 2025 GMT
*  subjectAltName: host "id.example.com" matched cert's "*.example.com"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://id.example.com/.well-known/openid-configuration
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: id.example.com]
* [HTTP/2] [1] [:path: /.well-known/openid-configuration]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /.well-known/openid-configuration HTTP/2
> Host: id.example.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< date: Fri, 20 Jun 2025 22:20:30 GMT
< content-type: application/json; charset=utf-8
< cf-ray: redacted-SEA
< access-control-allow-headers: Authorization
< access-control-allow-methods: GET, POST
< access-control-allow-origin: *
< alt-svc: h3=":443"; ma=86400
< vary: Accept-Encoding
< via: 1.1 Caddy
< cf-cache-status: DYNAMIC
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=redacted"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< strict-transport-security: max-age=15552000; includeSubDomains
< server: cloudflare
< server-timing: cfL4;desc="?proto=TCP&rtt=25025&min_rtt=8123&rtt_var=10615&sent=7&recv=12&lost=0&retrans=0&sent_bytes=2914&recv_bytes=595&delivery_rate=351755&cwnd=69&unsent_bytes=0&cid=4a67e378f22d06ba&ts=836&x=0"
< 
* Connection #0 to host id.example.com left intact

{
  "authorization_endpoint": "https://id.example.com/authorize",
  "claims_supported": [
    "sub",
    "given_name",
    "family_name",
    "name",
    "email",
    "email_verified",
    "preferred_username",
    "picture",
    "groups"
  ],
  "device_authorization_endpoint": "https://id.example.com/api/oidc/device/authorize",
  "end_session_endpoint": "https://id.example.com/api/oidc/end-session",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "introspection_endpoint": "https://id.example.com/api/oidc/introspect",
  "issuer": "https://id.example.com",
  "jwks_uri": "https://id.example.com/.well-known/jwks.json",
  "response_types_supported": [
    "code",
    "id_token"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "groups"
  ],
  "subject_types_supported": [
    "public"
  ],
  "token_endpoint": "https://id.example.com/api/oidc/token",
  "userinfo_endpoint": "https://id.example.com/api/oidc/userinfo"
}

[gtsteffaniak]

Ok , that helps a lot, I see two things happening:

1. the http request is getting redirected
2. the request is getting upgraded to http2

I bet one of these is the reason and probably the first one. You're using docker? Let me create a dev build I would like you to try

[gtsteffaniak]

oh I just re-read this on a computer as I was looking this up. It seems the issue is straight forward:

use it without authorize endpoint :

auth:
  methods:
    oidc:
      enabled: true
      clientId: "redacted"
      clientSecret: "redacted"
      issuerUrl: "https://id.mydomain.com"
      scopes: "email openid profile"
      userIdentifier: "username"
      disableVerifyTLS: false
      createUser: true

What jappens when you try that?

[mitchplze]

Amazing, that seems to have done the trick! Everything works as expected now with built-in OIDC. :) Thanks for the suggestion.

One little glitch I quickly noticed, maybe intentional though. I can split this into a new issue if you think it's worth it.

As a local admin if you assign an oidc user admin privileges manually in the ui (i.e.: not via adminGroup), the privilege is stripped for that user during their next oidc login, even when adminGroup is not defined (commented out) in FB config.

I think personally the privilege should remain, when adminGroup is not defined at all in config, as that would seem to imply the server operator does not want to manage admins with oidc groups at all.

[mitchplze]

If you want to add the below to your wiki, feel free (apparently you cannot do PRs to wikis)!

---

For Pocket ID (perhaps others): use just the bare URL of your server for issuerUrl instead of the "Authorization URL".

Example Pocket ID OIDC Authentication

auth:
  methods:
    oidc:
      enabled: true
      clientId: << Client ID >>
      clientSecret: << Client Secret >>
      issuerUrl: https://id.example.com
      scopes: email openid profile groups
      userIdentifier: username
      disableVerifyTLS: false
      createUser: true
      # Below is optional. Also add 'groups' to 'scopes' if using this
      adminGroup: filebrowser_admin

[mrnetlex]

As an another Pocket ID user who tried to troubleshoot this on his own, I can confirm that issuerUrl: https://id.example.com works. Including this in wiki would be welcome additon.

[gtsteffaniak]

Thanks for all the help getting this working - I have updated and made some corrections to the wiki. marking this issue closed