Single sign-on across subdomains via cookies & localStorage

[Zach Alexander]

I and I think a number others people would like to have true single sign-on (SSO) between my primary and secondary Meteor apps at the same apex domain (e.g.www.app.com and foo.app.com). In other words, when you're logged in at www.app.com, you're also logged in on foo.app.com, without having to do so twice.

Currently this is impossible (meteor.com/blog/2014/03/14/session-cookies) because foo.app.com cannot read the session token stored in the www.app.comlocalStorage. But it seems like cookies provide a workaround, at least for mutually-trusted subdomains, which is the most common scenario (sites with mutually untrusted subdomains like foo.meteor.com or foo.blogspot.com are a minority of websites).

Here is what I'm thinking:

0. Share the database between the two apps, so Meteor.users is the same collection.

1. On www.app.com, in Accounts.onLogin, get the session token from localStorage.

2. Set this session token in a cookie on www.app.com.

3. On foo.app.com, monitor the www.app.com cookies for the session token, and when it appears or changes, copy it to foo.app.com localStorage.

4. You are now automagically logged into foo.app.com, hopefully.

Has anyone tried this? Or does anyone have feedback on whether this is likely to work, or tips on where/how to implement this? In particular I'm not sure how to best implement #3, and unsure whether #4 is true or if I've missed a step.

Best,

Zach

[Arunoda Susiripala]

It should work. fast-render does similar by storing the token on cookies. (but not for sso).

I can't exactly see any issues with this approach, since it's your domain.

But someone like emily can answer better.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gabriel Pugliese]

I think that this feature is essential for making huge Meteor applications. That way we could split ours apps and make initial js/load optimized.

[Dal Chand Choudhary]

I'm using this... I have an application www.app.com and there is another service upload.app.com for handling all the file uploads. It works fine.

[Patrick Scott]

I'll also need the feature in the near future, though my use case is a bit different. I was planning on using an Iframe and postmessage to share the credentials from localstorage, but reading cookies on startup sounds like a better idea. Let us know if you take a stab at it!

[Emily Stark]

I'm a bit wary of this approach. From foo.app.com, you're setting a cookie for .app.com, which www.app.com is reading, right? (I don't think that there's any way foo.app.com to set a cookie for www.app.com only.) This means that any app.com subdomain can read the cookie, which is a little scary and lowers the security of your user's accounts to the security of your least-secure subdomain. (At the very very least, you'll want to use the 'secure' flag when setting the cookie and make sure that ALL subdomains are ssl-only, since even non-ssl subdomains will be able to set the login cookie.)

If you are only trying to share login state across a small number of subdomains, I think the invisible iframe/postMessage approach is much, much safer.

--