Our company has two websites. Both websites have their own subdomains (on same domain). Both websites are using the same LDAP server for authentication.
Is there a way to authenticate users only once, and allow the (authenticated) user to access either website so that we don't have to login in to each site separately? For example, I'm logged in to siteA.domain.org, then I click on siteB.domain.org -- in this case I wouldn't be prompted to login to siteB.domain.org because I'm already authenticated to siteA.domain.org.
You probably need to add some info to your question regarding how you're doing your authentication. OAuth is an authorisation protocol, with a side-effect of authentication in some circumstances. So (for example) in Google OAuth, the user signs in to Google, not your website. Your website can test if the user is signed in to Google, and if so, obtain an access/id token to know who the user is.
So it all depends how your site is choosing to handle "login"
Related
I am currently working on a React-Native project with my own backend
I have to use OAuth2, but I want to have the user enter their name and password and not forward them to Facebook / Google, for example
Any help?
The only grant types that allow acquiring tokens without redirects are the client_credentials and the password (resource owner password grant). Both of them are only feasible if you are running your own Identity Server (like Keycloak).
For identity federation with external systems, you will always need a flow that redirects the end user (at the very least in an iframe). The user authenticates against Google, not against your system. Google then issues a Token, and your application can verify the token was issued by Google. A system without a redirect would be equal to each and every user giving you their Google password.
This is the kind of thing that OAuth2 was designed to prevent, and so it is not possible.
How to keep maintain cookies and session across 3 different domain?
I am setting up a centralized authentication for our 3 products which has different domain, like abc.com, xyz.com and def.com. so i have created a login server like login.abc.com, where my centerlized login will occur. so whenever a user entered abc.com and login himself in login.abc.com, then he can access all 3 products, but the challenging is when he opens third products or second products how can i authenticate him? because it's in different domain and same cookies doesn't work in different domains. So if you have any idea to overcome from this problem, then please share your ideas.
how to store cookies or JWT token, so that other site can take that cookies/ token for validating with user
Note: Like google, if you signed-in in gmail, then you automatically logged-in in youtube, though they have different domain.
i want such architecture like google follows.
Single Sign on (SSO) is a user experience that a user signs in only one time. A user is automatically signed into other applications if the user has already signed into one application. The user's authentication session is maintained by the dedicated and centralized SSO service. In your example, the abc.com will remember user sign-in status, if user has been signed in to abc.com, user does not prompt for sign-in again whenever user tries to access applications in any other domain.
I am wondering if firebase function getAuth() somehow checks if the the website link to which the token was initially issued is the one that is requesting for the authorization status.
I am concerned that if a malicious website somehow had access to my Firebase.io link, and runs a simple getAuth() in the same browser as my Firebase based backend website, it will be able to access the Firebase token issued to the user of my website.
Any thoughts on it would be greatly appreciated.
Note: I work at Firebase
Firebase Authentication sessions are stored using LocalStorage accessible only to your domain. This means that the sessions are not accessible from domains outside of your control.
If you're using OAuth (Google, Facebook, Twitter, or GitHub login), then authentication is further restricted to your domain via our OAuth configuration in your Firebase dashboard, where you must explicitly authorize domains for access.
Users of email / password authentication can authenticate from any source, provided that the user has access to the password. In short, we ensure that the sessions stored for your domain are not accessible elsewhere. Our top priorities for this product are data security and making that security available to you (as the developer) easily and as the default.
If you have additional concerns that are sensitive for any reason, don't hesitate to reach out to me rob at firebase.com.
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...