You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] Support authenticating multiple domains #65
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.
Reacted by zdeneksvarc and Felitendo
Reacted by Adyanth Hosavalike, Andreas Molnar, Glenn Rempe, eddively, cerealconyogurt and Felitendo
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.
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.
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.
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.
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:
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.
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
Activity
steveiliop56 commentedon Apr 9, 2025
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.
danktankk commentedon May 19, 2025
+1 for this feature
danktankk commentedon Jun 6, 2025
I guess this didnt make it to the v3.3 release?
steveiliop56 commentedon Jun 6, 2025
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.comand have the app URL astnyauth.sub.domain.comyou will be able to login but if you have another service onmyservice1.sub1.domain.comunless tinyauth is ontinyauth.sub1.domain.comthere 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 thepinnedlabel in case someone has an idea.danktankk commentedon Jun 7, 2025
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.
1 remaining item
steveiliop56 commentedon Jun 7, 2025
It will be quite annoying to have one tinyauth instance and then
tinyauth.sub.domain.comandtinyauth.sub1.domain.compointing 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 exampleauth.domain.com) that will work for all of your subdomains.adyanth commentedon Jun 8, 2025
My use case had a different TLD, running a different instance it is. Thanks!
steveiliop56 commentedon Jul 5, 2025
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.
isc30 commentedon Jul 6, 2025
Hi, as a possible (easy) solution for this, you could read the
Hostheader when setting the cookie and redirecting. This wayAPP_URLwould NOT be required and work with all the domains you want.Another option, allow
?appUrl=XXXas a parameter when invoking/api/auth/nginx:/api/auth/nginx?appUrl=auth.my.homeI personally prefer option 1
steveiliop56 commentedon Jul 6, 2025
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 theX-Forwarded-Hostheader of theapp.example.comso it still wouldn't know the domain of itself to be able to redirect.adyanth commentedon Jul 6, 2025
Maybe I misunderstood some of your initial messages. Here is an example:
Tinyauth accessible on
auth1.a.comandauth2.b.com. Apps onapp1.a.com,app2.b.com,app3.c.com.auth1.a.comor evena.com.auth1.a.com.auth2.b.com.Does that work?
isc30 commentedon Jul 6, 2025
@adyanth it only works with 3 different instances, does anyone know how to get it working with a single instante of tinyauth?
adyanth commentedon Jul 6, 2025
this issue was to support that usecase.
danktankk commentedon Jul 10, 2025
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
youtiaoguagua commentedon Jul 16, 2025
+1
github-actions commentedon Aug 15, 2025
This issue has been inactive for 30 days and will be marked as stale.
github-actions commentedon Aug 23, 2025
Closed for inactivity.