Working with multiple frontend domains

[nathanpalmer]

Working with multiple frontend domains

[cainlevy]

That sounds like a reasonable API for subject_from.

One difference between that solution vs a config.audiences array is that passing subject_from(token, audience: 'frontend1.domain.com') would prevent sessions from leaking from one subdomain to another. Is that desirable in your use case?

[nathanpalmer]

Right now, yes. Though I could see us wanting to share in the future, we don't have that now.

With that said I didn't see a way to allow sessions from multiple sites with the way things are setup today. Since the audience is based on the referrer when you login from the front-end it's always going to be the domain you are logging under.

[nathanpalmer]

I'm happy to throw out a PR on this. But before I do I just want to make sure that how I'm thinking about usage here aligns with yours. When you say this:

One difference between that solution vs a config.audiences array is that passing subject_from(token, audience: 'frontend1.domain.com') would prevent sessions from leaking from one subdomain to another.

It makes me think that the default behavior should allow for a session to be started on one domain (say frontend1.domain.com) and be recognized on the second domain (say frontend2.domain.com)

After reading through the code here, and on the main authn codebase, since we're taking the referer header that doesn't be the case. Should it be?

[cainlevy]

You've got me thinking about this as well. Both of the storage mechanisms (cookies, localStorage) in the JavaScript client are also single-origin. Well, cookies can be cross-origin, but only across subdomains and even then in an unfortunately permissive way.

So currently I'm thinking that signing in across multiple origins will involve one access token (aka identity token) for each, all backed by the same refresh token (aka AuthN session). An application that expects some user to switch from one origin to the next would check for an existing refresh token and request a new access token for the new origin. This, I think, would require the AuthN server to be configured with the full list of possible origins (or possibly a regex for dynamic subdomains).

The upshot for this issue at hand seems to be: let's double-down on one access token per origin and solve for cross-origin single sign-on later.

I'm happy to throw out a PR on this.

Thanks in advance! 👍

[nathanpalmer]

So currently I'm thinking that signing in across multiple origins will involve one access token (aka identity token) for each, all backed by the same refresh token (aka AuthN session).

Yeah, this sounds right to me.