In the company I'm currently working at there are multiple WebApps, e.g: App1, App2, App3 ... The current issue is that we want to allow an user to log into App1, and if he goes to App2 we do not require this user to login again, because he already logged in App1.
How can I achieve this? I'm using Firebase but the onAuthChange() doesn't track changes on different domains, and I'm aware I cannot share cookies from App1.com to App2.com.
My plan was to once a user signs in in App1, I create a cookie on the browser that I could check on App2 and if there is a current user, get the ID and fetch the data needed to render the user information.
I'm working with: ReactJs, NodeJs, Graphql, Prisma, Nexus, Firebase (Auth). In case it matters
Cookies are not shared across different domains. But if the sites app1, app2, app3 have a common sub domain, then they can share the cookies. For example app1.example.com, app2.example.com, app3.example.com. All these sites have *.example.com as their sub-domain. So a cookie set for *.example.com can be accessed by all these web-apps.
These web-apps need to have a common authentication mechanism shared among them.
Another option is when you authenticate with app1, then response can include cookies for all three domains.
Related
I am currently creating a microserices some of which will be hosted on different url. How can I implement the same, I mean if I login with 1 url, I can access all the websites.
My thinking is that I'll create a master authentication as a middleware which will check all request from all urls and allow those that have been authenticated
I have multiple front-end & back-end apps running on different subdomains of the same domain. On the main front-end app I want to build a thing to switch between subdomains but also keep the session.
I've tried to:
use express-session
do some tricks with the JWT authentication
localStorage is not going to work as it is persistent on only 1 URL
but still can't figure out:
Is it possible to have a session shared across multiple subdomains?
What is the best solution to have a shared session across multiple subdomains?
The technologies I use:
Front-end: React JS
Back-end: Node & Express JS
To share sessions across sub-domains, you need to configure two things.
You need the proper cookie settings for the session cookie so that the browser will send the same session cookie to both sub-domains. This involves setting the domain attribute on the cookie to the root domain. You can set this in the cookie options for the express-session configuration.
You need to make sure that the server for each sub-domain has access to the same session store. If it's actually the same server for each sub-domain, then that's easy. But, if it's a different server, then you will need a shared session store, using some type of shared database (redis, mongodb, etc...). There are session store implementations for many different databases.
Luckily we're working on same project these days with with Nextjs as frontend and nodejs express as backend API.
We use cookies to manage the session on sub domains.
But to maintain the session on sub domains we use middleware in nextjs which on every page check for the session using token and user id.
On login send token, userid as parameters in url based on which user data get from api and saved that subdomain.
On logout removing cookies and sending paramter to tell the main domain to remove the saved cookies which completely clean the session.
This is how we maintain the auth session on multiple domains.
Hope this will helps.
If you find other way better then this i would like to know.
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
anybody know is possible to use Persona for SSO purposes for cross site login which are sub domains of the single domain ? I do no find this useful feature in documentation.
thanks.
If all of the services are within a single domain (e.g. service1.example.com, service2.example.com, etc.), you could set a cookie on the top-level domain directly (example.com) and then all services could use the same session since they would all have access to that session cookie.
So one way to do this would be to redirect users to login.example.com when they click the login button on any of the other sites (service*.example.com). That login service would use Persona to ask the user to login and then it would set a cookie on example.com.
This strategy is of course not specific to Persona, it's a common way to get SSO between internal services within a company for example.
We have a large number of websites which need to implement cross domain login, ie. If someone is logged in to site X with the credentials, he should automatically login to the site A or B when the user navigates to site A or B.
Also, we want to give a common UI/Javascript, which all the sites can put on their HTML file, and which will internally call a common API and which will somehow log the user in the site A or B.
Its is similar to what Facebook has. If one logs on to facebook, and goes to a site, he will automatically be logged in, if he has given the permissions for that site.
Also, the same facebook UI is present on every site which has the facebook social plugin, and the site including the facebook plugin does not have to make any call to facebook from its own server(i guess that call is made from the browser).
I saw that a call to facebook includes an API key which is used by that app, but since the API key is visible, it is no longer a secret. How does FB prevent random DOS attacks to its servers by the same API key, and if the user changes his IP address at random?
Lets say we try to implement similar of all the websites A, B which are associated with X, since the API key is exposed(just like in case of FB), how can i stop a different rogue site, say ABC.com from using the same API key, and acting as if it was part of the network.
I guess since the call is from the browser, and from a javascript, the API key is always exposed. Does the call always have to be from the server so that the API key is kept a secret?
In my case, how can the UIs of various networked websites like A, B etc pass something to the server of X, so that the server X can identify that the call is indeed coming from a reliable source and is not impersonated?
Thank you
Tuco
I saw that a call to facebook includes an API key which is used by that app, but since the API key is visible, it is no longer a secret.
No one ever said it was.
How does FB prevent random DOS attacks to its servers by the same API key, and if the user changes his IP address at random?
For certain actions, f.e. login, apps are tied to certain domains set up in the app settings. If my app allows user logins through Facebook from example.com, logins will not work if example.net takes my app id and tries to have users connect to it from their domain.
I guess since the call is from the browser, and from a javascript, the API key is always exposed. Does the call always have to be from the server so that the API key is kept a secret?
Calls using the app secret should always be made server-side only.
In my case, how can the UIs of various networked websites like A, B etc pass something to the server of X, so that the server X can identify that the call is indeed coming from a reliable source and is not impersonated?
The Facebook JS SDK checks for example which domain it is currently running on.
Since that’s client side and could be manipulated, there’s other security measures in place as well. F.e., Facebook will only redirect a client to addresses under a certain domain, and in server-side communication gives you a signed_request which can be verified using your app secret.