Skip to content

[FEATURE] Support authenticating multiple domains #65

Closed as not planned
Closed as not planned

Description

@adyanth

Is your feature request related to a problem? Please describe.

I have two domains, one resolvable only locally, one from the internet. Most services have both domain URLs accessible.

Describe the solution you'd like
TinyAuth should support accepting a list of domains to set cookies on and protect, not just its parent domain.

Describe alternatives you've considered
thomseddon/traefik-forward-auth#302

Additional context
N/A

Activity

  1. steveiliop56 commented on Apr 9, 2025

    @steveiliop56
    Member

    Hello,

    I would definitely like to add this too. I actually started writing some of the code but later I scrapped it because I wasn't happy with the implementation I had. I will rework it in the next release though and hopefully this time it will be better.

  2. moved this to Backlog in Tinyauthon Apr 9, 2025
  3. moved this from Backlog to Priority in Tinyauthon Apr 9, 2025
  4. added this to the v3.3.0 milestone on Apr 14, 2025
  5. removed this from the v3.3.0 milestone on Apr 23, 2025
  6. moved this from Priority to Backlog in Tinyauthon May 1, 2025
  7. danktankk commented on May 19, 2025

    @danktankk

    +1 for this feature

  8. danktankk commented on Jun 6, 2025

    @danktankk

    I guess this didnt make it to the v3.3 release?

  9. steveiliop56 commented on Jun 6, 2025

    @steveiliop56
    Member

    Unfortunately no. I had an idea on how to implement it but I ended up not liking it and toasted it. The issue is that if you make a request to myservice.sub.domain.com and have the app URL as tnyauth.sub.domain.com you will be able to login but if you have another service on myservice1.sub1.domain.com unless tinyauth is on tinyauth.sub1.domain.com there is no way to set the cookie. I cannot think of a good idea on how to implement this because you will need to have tinyauth exposed on multiple domains which is not really practical. I think the best way going forward is to have a tinyauth instance per domain. I will leave this open but remove the pinned label in case someone has an idea.

  10. danktankk commented on Jun 7, 2025

    @danktankk

    This was an issue for James over at authelia as well. He did manage to get it sorted out, but it did take a while. No worries. I am currently running one per domain already. I just like to consolidate where possible. FWIW, personally, I dont use sub.sub.domain.com anyway as it seems to be somewhat problematic for services anyway. All good. Thank you for your work and efforts.

  11. 1 remaining item

  12. steveiliop56 commented on Jun 7, 2025

    @steveiliop56
    Member

    It will be quite annoying to have one tinyauth instance and then tinyauth.sub.domain.com and tinyauth.sub1.domain.com pointing to the same instance. Since tinyauth is extremely lightweight running one per subdomain is not that bad or you could just run one in the root domain (for example auth.domain.com) that will work for all of your subdomains.

  13. adyanth commented on Jun 8, 2025

    @adyanth
    Author

    My use case had a different TLD, running a different instance it is. Thanks!

  14. steveiliop56 commented on Jul 5, 2025

    @steveiliop56
    Member

    Adding to this, pull request #232 adds support for LDAP. This means that you can have multiple tinyauth instances in different domains all getting their user information from a centralized server making the overall configuration match easier.

  15. isc30 commented on Jul 6, 2025

    @isc30

    Hi, as a possible (easy) solution for this, you could read the Host header when setting the cookie and redirecting. This way APP_URL would NOT be required and work with all the domains you want.

    Another option, allow ?appUrl=XXX as a parameter when invoking /api/auth/nginx:

    • /api/auth/nginx?appUrl=auth.my.home

    I personally prefer option 1

  16. steveiliop56 commented on Jul 6, 2025

    @steveiliop56
    Member

    For the second part this would only work with nginx proxy manager so it is a bit out of the question. As for the first suggestion I am not really sure I understood how this would work. When you make a request to a protected app (e.g. app.example.com), tinyauth will only receive the X-Forwarded-Host header of the app.example.com so it still wouldn't know the domain of itself to be able to redirect.

  17. adyanth commented on Jul 6, 2025

    @adyanth
    Author

    Maybe I misunderstood some of your initial messages. Here is an example:

    Tinyauth accessible on auth1.a.com and auth2.b.com. Apps on app1.a.com, app2.b.com, app3.c.com.

    • accessing app1, if the reverse proxy redirects to auth1, the cookie is set on auth1.a.com or even a.com.
    • accessing app2, if the reverse proxy redirects to auth1, the cookie is set on auth1.a.com.
    • accessing app3, if the reverse proxy redirects to auth2, the cookie is set on auth2.b.com.

    Does that work?

  18. isc30 commented on Jul 6, 2025

    @isc30

    @adyanth it only works with 3 different instances, does anyone know how to get it working with a single instante of tinyauth?

  19. adyanth commented on Jul 6, 2025

    @adyanth
    Author

    this issue was to support that usecase.

  20. danktankk commented on Jul 10, 2025

    @danktankk

    In my situation, and not to hijack this thread, I am just using 3 different tinyauth containers currently. One for each domain I want covered. All 3 of these forward to one instance of pocketid. works without any issues. Obviously it would be easier to deploy once for all domains, but it isnt too bad this way either

  21. youtiaoguagua commented on Jul 16, 2025

    @youtiaoguagua

    +1

  22. github-actions commented on Aug 15, 2025

    @github-actions
    Contributor

    This issue has been inactive for 30 days and will be marked as stale.

  23. github-actions commented on Aug 23, 2025

    @github-actions
    Contributor

    Closed for inactivity.

  24. moved this from Backlog to Done in Tinyauthon Aug 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requeststaleThis issue or pull request is stale

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions