Access Control: Set JWT Secret -> From Another Site's Identity Instance

Features
,
1

Greetings Team :wave:t2:

After a long discussion with @james-king and @chriso0710 over in this thread:

https://answers.netlify.com/t/identity-role-based-access-control-across-subdomains/

It’s become clear that it’s currently quite painful / not feasible to try to use Netlify Identity for providing single-site-sign-on authentication across multiple sites / subdomains, e.g. having login.example.com which provides a single login for private.example.com and gated.example.com and portal.example.com. @DavidWells’s previous tutorial (Okta Single Site Sign on w/ Netlify Access Control & Serverless Functions - YouTube) leverages Okta and a number of Functions to accomplish this task, but that ignores all of the development and efforts that have gone into creating great bindings and integrations with Netlify Identity over the years (identity widget, Netlify CMS, etc).

I recognize that for security concerns Netlify opts to not release the signing key used by the GoTrue instances that power Netlify Identity, but without knowing that key and setting it as the ‘Set JWT Secret’ value for another site, the login.example.com site (running an identity instance) could never create JWT tokens that another site could validate (since the other site doesn’t know the signing key).

This feature request is for an alternate path that continues to not expose the key. When clicking the “Set JWT Secret” button under “Access Control” in a site’s settings, it would be great if there were two options:

Set JWT Secret (Manually)
This would be the current workflow, where the user types in the JWT Secret and it’s saved. Done :+1:t2:

Set JWT Secret (From Another Site)
This option would essentially give the user a dropdown or selector of all current sites that have Netlify Identity enabled, and upon choosing one, would (behind the scenes) apply that site’s GoTrue instance’s signing key as the JWT Secret for this site, allowing JWT’s issued from the other site to be used for role-validation in _redirects on this site.

A note: this really is tailored for the subdomains case (which is the most common) since GoTrue is already built to send back a set-cookie header that should send the cookie to other subdomains.

Happy to answer any subsequent questions!

Cheers :netliheart:

–
Jon

4 Likes
2

This feature would be really useful! Thanks for writing this up @jonsully

1 Like
3

100% Agree with you man. Great Request :grinning: :netliheart:

1 Like
5

Hi @jonsully, just wanted to confirm that I have filed the feature request. I’m not sure when or if the feature will be implemented, though. But we’ll update here if it does.

1 Like
6

What is the concern about being able to set our own JWT secret? Or at least being able to access the public key of an asymmetrical encryption algorithm used to sign the JWT.

This would let us at least verify the paternity of the tokens, and trust the claims contained into it. It would unlock easy integration with legacy services.

7

I’m not aware of any concerns as such, it’s just that this feature was not implemented.

The feature request is still open and we would update the thread if or when it gets implemented.