I got a chance to check in with Dennis and at this current time there is no means or availability for determining the signing key used by a site’s GoTrue instance. For fun and giggles I also tried cracking one of the JWTs but to no avail they must use long signing keys (which they should, but hey, experiments ).
So that essentially means that to get multi-site auth we can either:
Build a fully separate JWT provider that sets the correct cookie key a la @chriso0710
Use an external provider (like Okta) then a single Function that runs post-sign-in to set the cookie key on login.example.com which should be sent to other subdo’s automatically
Use Netlify Identity and a Function that runs post-sign-in to set the cookie key (same as above) though the Function’s set-cookie would override the cookie sent directly back from GoTrue… so you’d basically log in at login.example.com then get access to all the other subdo’s, but then register as logged out from login.example.com so not exactly elegant, but it would work if you want to use Netlify Identity and its associated tooling.
Wish I had better news I may play with this in the future using SupaBase since it’s (mostly) GoTrue-based and may be easier to play with than Okta.
In my opinion it is not “rocket science” to build your own jwt auth provider. Altough there are a few tricky things to be aware of, so you have to do your homework and RTFM It took a couple of days.
But for me as a Rails developer this approach seemed the best and made more sense than GoTrue, Identify or external commercial providers.
Our auth provider API runs Rails on heroku (hobby dynos ATM) and uses a small heroku postgres as the database.
When I have time, I’ll try the Okta & single function on the login subdomain to set a portable cookie. At the moment I have Okta + Functions on each subdomain (as per David Well’s tutorial) and it is working OK for now. I believe @DavidWells is no longer at Netlify and is probably not gonna respond in this forum, but I would love to know why his tutorial creates a new cookie for each subdomain.
Yeah - I was thinking about this - basically Netlify Identity is not really set up to handle this use case elegantly.
I hadn’t checked until now but I believe that’s true as well. My presumption is that he really was just building sites on the .netlify.app public suffix, at which point you would need functions for each site… I’m pretty sure that if you’re using your own domain you’ll be fine with a single
Unfortunately, I agree. I even spent a significant number of hours letting my machine run hashcat yesterday to see if I could crack the JWT secret for one of my identity instances (for science!!) but no luck. They do use pretty strong keys (which is good).
For what it’s worth, in chatting more with Dennis I came up with an idea that would allow this sort of functionality to happen without actually having to tell users what the signing key for their instance is — some sort of button that would allow you to say “Apply this Identity instance’s signing key to another site in my Team as the external JWT Secret”. Frankly though, Netlify is working on a ton of stuff and this probably won’t be a high priority request… but we’ll see where it goes.
I totally agree here as well, especially as a Rails developer myself too. That said, the nature of JAMstack is to weld APIs and parts together in some sort of agreeable way. I’d love to see this functionality ‘just work’ with Netlify Identity.
they must use long signing keys (which they should, but hey, experiments 
).
so not exactly elegant, but it would work if you want to use Netlify Identity and its associated tooling.
I may play with this in the future using SupaBase since it’s (mostly) GoTrue-based and may be easier to play with than Okta.
It took a couple of days.