starred/godoxy-yusing
1
0
Fork 0
mirror of https://github.com/yusing/godoxy.git synced 2026-01-14 23:53:40 +01:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

Using TinyAuth with Godoxy (as OIDC ?) #50

New Issue
Closed
opened 2025-12-29 14:23:22 +01:00 by adam · 17 comments
adam commented 2025-12-29 14:23:22 +01:00
Owner
Copy Link

Originally created by @simon-dmsn on GitHub (Apr 1, 2025).

Hello everyone,

I hope it is the right place to ask !

I would like to use TinyAuth which is a tiny but really useful open source project for authenticating all the services and apps that we host on our homelabs.

But I cannot really know how to do that. TinyAuth has a guide for Traefik, Caddy and NPM but none of them seems to be relevant enough for Godoxy. It seems that a way to use it would be to use the OIDC capability of Godoxy, but I have no idea why.

It would be amazing if you are able to explain how could I do that. And if it is not possible, thinking of maybe make it compatible with it (either by discussing with the maintainer of TinyAuth as the project is evolving a lot, or by evolving Godoxy itself) !

Thank you very much for all the work that have been done with Godoxy, I really love that project and it works like a charm !

Have a nice day :)

Originally created by @simon-dmsn on GitHub (Apr 1, 2025). Hello everyone, I hope it is the right place to ask ! I would like to use [TinyAuth ](https://github.com/steveiliop56/tinyauth) which is a tiny but really useful open source project for authenticating all the services and apps that we host on our homelabs. But I cannot really know how to do that. TinyAuth has a guide for Traefik, Caddy and NPM but none of them seems to be relevant enough for Godoxy. It seems that a way to use it would be to use the OIDC capability of Godoxy, but I have no idea why. It would be amazing if you are able to explain how could I do that. And if it is not possible, thinking of maybe make it compatible with it (either by discussing with the maintainer of TinyAuth as the project is evolving a lot, or by evolving Godoxy itself) ! Thank you very much for all the work that have been done with Godoxy, I really love that project and it works like a charm ! Have a nice day :)
adam added the enhancement label 2025-12-29 14:23:22 +01:00
adam closed this issue 2025-12-29 14:23:22 +01:00
adam commented 2025-12-29 14:23:23 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Apr 2, 2025):

I gave up on the ForwardAuth middleware, so a simple answer is NO for now.

@yusing commented on GitHub (Apr 2, 2025): I gave up on the `ForwardAuth` middleware, so a simple answer is NO for now.
adam commented 2025-12-29 14:23:23 +01:00
Author
Owner
Copy Link

@tribor commented on GitHub (Apr 27, 2025):

Could you please provide some more information on the reasons behind this decision? What are the alternatives for using basic-auth protection or a similar solution like tinyauth?

@tribor commented on GitHub (Apr 27, 2025): Could you please provide some more information on the reasons behind this decision? What are the alternatives for using basic-auth protection or a similar solution like tinyauth?
adam commented 2025-12-29 14:23:24 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Apr 27, 2025):

Could you please provide some more information on the reasons behind this decision? What are the alternatives for using basic-auth protection or a similar solution like tinyauth?

Because I've spent some time on it but can't get it working with Authentik's ForwardAuth (probably skill issue). Back then tinyauth didn't exist yet. I may try again sometime in the future if you guys need forwardAuth.

The alternative is to use OIDC like Pocket ID and authentik, with the OIDC middleware for apps that don't have native OIDC support.

@yusing commented on GitHub (Apr 27, 2025): > Could you please provide some more information on the reasons behind this decision? What are the alternatives for using basic-auth protection or a similar solution like tinyauth? Because I've spent some time on it but can't get it working with Authentik's ForwardAuth (probably skill issue). Back then tinyauth didn't exist yet. I may try again sometime in the future if you guys need forwardAuth. The alternative is to use OIDC like Pocket ID and authentik, with the [OIDC middleware](https://github.com/yusing/godoxy/wiki/Middlewares#oidc) for apps that don't have native OIDC support.
adam commented 2025-12-29 14:23:24 +01:00
Author
Owner
Copy Link

@xd003 commented on GitHub (May 16, 2025):

I too would love to see ForwardAuth being implemented.
I'm planning to use Pocket ID as my OIDC provider, but since not all services support OIDC out of the box, I’ve chosen TinyAuth as a lightweight and efficient middleware to bridge that gap. While many people opt for solutions like Authentik, it’s far too heavy for typical self-hosting scenarios, and I’d prefer to avoid that overhead.

@xd003 commented on GitHub (May 16, 2025): I too would love to see `ForwardAuth` being implemented. I'm planning to use Pocket ID as my OIDC provider, but since not all services support OIDC out of the box, I’ve chosen TinyAuth as a lightweight and efficient middleware to bridge that gap. While many people opt for solutions like Authentik, it’s far too heavy for typical self-hosting scenarios, and I’d prefer to avoid that overhead.
adam commented 2025-12-29 14:23:25 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (May 17, 2025):

since not all services support OIDC out of the box

That's why the OIDC middleware exists. I'd like to implement forwardauth though, if I have time.

@yusing commented on GitHub (May 17, 2025): > since not all services support OIDC out of the box That's why the OIDC middleware exists. I'd like to implement forwardauth though, if I have time.
adam commented 2025-12-29 14:23:25 +01:00
Author
Owner
Copy Link

@xd003 commented on GitHub (May 21, 2025):

That's why the OIDC middleware exists. I'd like to implement forwardauth though, if I have time.

Agreed but the usecase here is bit different.
OIDC middleware can be used to protect apps only if the app supports native OIDC authentication. In all other cases, people always fallback to using forwardauth.

I use the following setup myself -
If the application supports OIDC natively → use PocketID directly.
If the application does not support OIDC → use TinyAuth's forward auth in front of it. ( i have added tinyauth as a oidc client in PocketID, so the app goes through tinyauth -> pocketid -> application page)

@xd003 commented on GitHub (May 21, 2025): > That's why the OIDC middleware exists. I'd like to implement forwardauth though, if I have time. Agreed but the usecase here is bit different. OIDC middleware can be used to protect apps only if the app supports native OIDC authentication. In all other cases, people always fallback to using forwardauth. I use the following setup myself - If the application supports OIDC natively → use PocketID directly. If the application does not support OIDC → use TinyAuth's forward auth in front of it. ( i have added tinyauth as a oidc client in PocketID, so the app goes through tinyauth -> pocketid -> application page)
adam commented 2025-12-29 14:23:25 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (May 21, 2025):

Incorrect, the OIDC middleware is for apps that doesn't support OIDC natively.

@yusing commented on GitHub (May 21, 2025): Incorrect, the OIDC middleware is for apps that doesn't support OIDC natively.
adam commented 2025-12-29 14:23:25 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (May 21, 2025):

For apps that have native OIDC support, set up OIDC in the app instead of using the middleware.

@yusing commented on GitHub (May 21, 2025): For apps that have native OIDC support, set up OIDC in the app instead of using the middleware.
adam commented 2025-12-29 14:23:26 +01:00
Author
Owner
Copy Link

@xd003 commented on GitHub (May 21, 2025):

Oh my bad, i am not really into networking so got confused by the technical terms. it seems like the oidc middleware in this context is alternative for the forwardauth we know. And for apps that support oidc natively, we just set it up on the app's end directly

Hope i have understood it correctly now

@xd003 commented on GitHub (May 21, 2025): Oh my bad, i am not really into networking so got confused by the technical terms. it seems like the oidc middleware in this context is alternative for the forwardauth we know. And for apps that support oidc natively, we just set it up on the app's end directly Hope i have understood it correctly now
adam commented 2025-12-29 14:23:26 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (May 22, 2025):

t seems like the oidc middleware in this context is alternative for the forwardauth we know. And for apps that support oidc natively, we just set it up on the app's end directly

Yes, you're correct

@yusing commented on GitHub (May 22, 2025): > t seems like the oidc middleware in this context is alternative for the forwardauth we know. And for apps that support oidc natively, we just set it up on the app's end directly Yes, you're correct
adam commented 2025-12-29 14:23:26 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Sep 3, 2025):

Happy to announce that ForwardAuth is now available! Please try it out!

@yusing commented on GitHub (Sep 3, 2025): Happy to announce that ForwardAuth is now available! Please try it out!
adam commented 2025-12-29 14:23:27 +01:00
Author
Owner
Copy Link

@FrozenFrog commented on GitHub (Sep 6, 2025):

@yusing seems like bypass is not working in config.yml on my machine with latest release

middlewares:
  - use: CloudflareRealIP
  - use: ForwardAuth
    bypass:
      - route tinyauth
      - route pocketid
      - route file
      - route jellyfin
      - route alist & path /*
      - route vaultwarden & path /api/* | path /identity/*
      - path /api/*
@FrozenFrog commented on GitHub (Sep 6, 2025): @yusing seems like bypass is not working in config.yml on my machine with latest release ``` middlewares: - use: CloudflareRealIP - use: ForwardAuth bypass: - route tinyauth - route pocketid - route file - route jellyfin - route alist & path /* - route vaultwarden & path /api/* | path /identity/* - path /api/* ```
adam commented 2025-12-29 14:23:27 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Sep 6, 2025):

@yusing seems like bypass is not working in config.yml on my machine with latest release

middlewares:
  - use: CloudflareRealIP
  - use: ForwardAuth
    bypass:
      - route tinyauth
      - route pocketid
      - route file
      - route jellyfin
      - route alist & path /*
      - route vaultwarden & path /api/* | path /identity/*
      - path /api/*

Could you explain briefly which part doesn't work? And the expected behavior compared to the actual behavior?

@yusing commented on GitHub (Sep 6, 2025): > @yusing seems like bypass is not working in config.yml on my machine with latest release > ``` > middlewares: > - use: CloudflareRealIP > - use: ForwardAuth > bypass: > - route tinyauth > - route pocketid > - route file > - route jellyfin > - route alist & path /* > - route vaultwarden & path /api/* | path /identity/* > - path /api/* > ``` Could you explain briefly which part doesn't work? And the expected behavior compared to the actual behavior?
adam commented 2025-12-29 14:23:28 +01:00
Author
Owner
Copy Link

@FrozenFrog commented on GitHub (Sep 7, 2025):

My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication

@FrozenFrog commented on GitHub (Sep 7, 2025): My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication
adam commented 2025-12-29 14:23:28 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Sep 8, 2025):

My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication

I have tested with the exact bypass configurations and it works. Please make sure that:

  1. You don't have the tinyauth middleware on the alist route itself
  2. The alias alist matches the route (route alist does not apply to container with FQDN alias like alist.domain.com)
@yusing commented on GitHub (Sep 8, 2025): > My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication I have tested with the exact `bypass` configurations and it works. Please make sure that: 1. You don't have the tinyauth middleware on the alist route itself 2. The alias `alist` matches the route (`route alist` does not apply to container with FQDN alias like `alist.domain.com`)
adam commented 2025-12-29 14:23:28 +01:00
Author
Owner
Copy Link

@FrozenFrog commented on GitHub (Sep 8, 2025):

My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication

I have tested with the exact bypass configurations and it works. Please make sure that:

  1. You don't have the tinyauth middleware on the alist route itself
  2. The alias alist matches the route (route alist does not apply to container with FQDN alias like alist.domain.com)

Yes, you are correct. I have defined forward_auth.headers: Authorization on alist compose. Removing it and godoxy bypass automatically. But I define bypass on docker compose (like oidc), it doesnt work

proxy.#1.middlewares.forward_auth.bypass:
OR
proxy.#1.middlewares.forward_auth.bypass: path /*
@FrozenFrog commented on GitHub (Sep 8, 2025): > > My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication > > I have tested with the exact `bypass` configurations and it works. Please make sure that: > > 1. You don't have the tinyauth middleware on the alist route itself > 2. The alias `alist` matches the route (`route alist` does not apply to container with FQDN alias like `alist.domain.com`) Yes, you are correct. I have defined forward_auth.headers: Authorization on alist compose. Removing it and godoxy bypass automatically. But I define bypass on docker compose (like oidc), it doesnt work ``` proxy.#1.middlewares.forward_auth.bypass: OR proxy.#1.middlewares.forward_auth.bypass: path /* ```
adam commented 2025-12-29 14:23:28 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Sep 8, 2025):

My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication

I have tested with the exact bypass configurations and it works. Please make sure that:

  1. You don't have the tinyauth middleware on the alist route itself
  2. The alias alist matches the route (route alist does not apply to container with FQDN alias like alist.domain.com)

Yes, you are correct. I have defined forward_auth.headers: Authorization on alist compose. Removing it and godoxy bypass automatically. But I define bypass on docker compose (like oidc), it doesnt work

proxy.#1.middlewares.forward_auth.bypass:
OR
proxy.#1.middlewares.forward_auth.bypass: path /*

Those labels are controlling the middleware on the "alist route" and has nothing to do with the entrypoint one.

@yusing commented on GitHub (Sep 8, 2025): > > > My expectation: the route for Alist should be bypassed from TinyAuth checks (similar to how it works with OIDC bypass). But on my machine, define bypass in config.yml doesnt work. Accessing alist.domain.com redirect to tinyauth’s authentication > > > > I have tested with the exact `bypass` configurations and it works. Please make sure that: > > > > 1. You don't have the tinyauth middleware on the alist route itself > > 2. The alias `alist` matches the route (`route alist` does not apply to container with FQDN alias like `alist.domain.com`) > > Yes, you are correct. I have defined forward_auth.headers: Authorization on alist compose. Removing it and godoxy bypass automatically. But I define bypass on docker compose (like oidc), it doesnt work > ``` > proxy.#1.middlewares.forward_auth.bypass: > OR > proxy.#1.middlewares.forward_auth.bypass: path /* > > ``` Those labels are controlling the middleware on the "alist route" and has nothing to do with the entrypoint one.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pull-request
Mirrored from GitHub Pull Request
 wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/godoxy-yusing#50
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?