All sites use the same database and there are no third party websites involved.
I think there may be a way to do this by opening an iframe to auth.foo.com with a token (also saved in the database) in the url params, and then auth.foo.com checks for a logged in user and updates the document for the token with the user’s userId. The original site (e.g. www.bar.com) then logs the user in based on the userId that was added to the document.
I also think that someone is going to point out a security flaw or three with this, so would rather use an existing & tested solution that works with Meteor. All sites will be TLS (https) only.
Any experience or comments would be appreciated!
Thanks!
@seba thanks for your reply. I should have said ideally I don’t want to use something like SAML (assuming there is even implementations using Meteor?).
I would consider OpenID Connect if there was a suitable solution in Node or Meteor but I haven’t seen anything particularly impressive yet. I did find a solid OAuth 2 Node/Express server but implementing OpenID Connect on top of that is probably outside my ability level and available time. It’s not easy stuff, hence why I want to keep it as simple as possible without compromising security.
@mjmasn - I was slow to setup Oauth because my last experience with SAML and other third party providers was a huge waste of time (not in the Meteor environment). However, meteor makes it as easy as possible to implement third party ID providers and, personally, I would recommend you consider using them, starting with the Google provider as it is the most flexible and moving on to Github providers. Now when I need to set up a provider it takes less than a minute.
But I wonder about your setup. What is the purpose of your auth domain? If it is essentially an ID provider and nothing more, I would definitely move to the OAuth support in meteor. If you have no experience, or even if you do with similar technologies (e.g. SAML) it should still take less than an hour for the first configuration.
The nice thing is you can then take advantage of the latest technologies, patterns and thinking in this area.
@seba - agreed, and understand. My comment is directed more to what is the requirement - use the same credentials for all logins or login once and access multiple “apps”. If the only requirement is to use the same credentials for all logins, then I think best practice is OpenID Connect. If the requirement is to login once and access multiple apps why would you prefer subdomains over internal routes? I am interested in knowing why you would choose subdomains over routes since routes are so much easier to manage and secure and do not require resorting to using iframes.
For instance, if the documentation for your application is meant to be public then docs.myapp.com would work well where docs.myapp.com is a public facing website while myapp.com requires a login. However, if the docs are meant to be private then myapp.com/docs would allow better (and simpler) control over access than having a login.myapp.com, docs.myapp.com and myapp.com all sharing the login from login.myapp.com.
I am fairly new to this so I could be not looking at this correctly. In my experience you need only resort to SAML and other federated login patterns when you need to control access of internal users to external resources and you have established a trusted relationship with the external resource. Thus, when a user logs in to their organization’s network they do not need to provide credentials for any federated resource external to the organization. In the example above it would mean the login.myapp.com is no longer needed since a true “SSO” is accomplished through federation using SAML.
But, as I stated before, there are so many headaches and moving parts with that approach it is really not worth it.
@mcrayne Just to clarify - In this case the requirement is for users to login once and access multiple apps. We only allow email address / password logins and if a user has access to more than one of our sites they will use the same credentials for each site. We don’t use facebook/twitter/github etc. logins.
I agree subdomains aren’t ideal compared to using subdirectories (not just for auth, but also for SEO, and keeping the number of SSL certificates we need to manage a bit lower) but the websites I’m working on are different ‘brands’ and distinct products so must be on separate domains. Our main company name domain doesn’t currently host any ‘app’ so it makes sense for auth.company.com to be a separate subdomain. In general though, within a brand, we use HAProxy to route urls like domain.com/blog and domain.com/docs to different servers/apps.
I think the window.postMessage technique used in the shared-auth package should fulfil our needs for the foreseeable future. Thanks for everyone’s comments!
How do you use this package, because I get message “Error logging in with token: Error: You’ve been logged out by the server. Please log in again. [403]” when refresh page?
