Let's say I have the following sites: ClientSiteA.com, ClientSiteB.com, ClientSiteC.com, MainServer.com
I am distributing a software to client sites. Anyone will be able to install the software so a site can not be considered trusted. MainServer.com will contain user information.
Users will interact with the software on client sites. A user will be able to click a login link on any client site which will bring up a popup. The popup can reside on MainServer.com. When a user logs in on any client, they will be logged in on ALL client sites as well as the MainServer.com. Remember, MainServer.com contains all user information.
I've done a lot of reading on SAML and OAuth2. Can someone tell me what is possible? If it is possible, which tools/workflows should I use? If this isn't possible, can someone tell me something I can accomplish that is similar to this?
FYI - I am trying to accomplish something like what Disqus does. If you login to Disqus on any site, you are logged into all the sites.
You can accomplish this with SAML, although it will involve browser redirects not popups.
The first time use hits a protected site (ClientA) it redirects to MainServer.com. The user logs in, MainServer gives them a session and redirects them back to the service provider with a SAML authentication statement which then lets them in.
When the user then visits ClientB.com, it also redirects to MainServer.com for authentication. Because the user is already logged at MainServer it can invisibly bounce them straight back to ClientB.com with a new authentication statement. The user barely if at all notices.
The problem with the pop-up window approach is that users have to give their credentials for site A to site B. This is a big security hole if site B isn't owned and controlled by Site A. Users should only give their credentials to the site that is authenticating them to prevent them being compromised. SAML and other federated/distributed auth mechanisms were designed with that in mind. I wouldn't want to give the keys to my email account to random sites on the internet but with this method I can log into stackoverflow with my gmail account.
Related
Using this page: https://developers.google.com/identity/sign-in/web/sign-in
It's really easy to add a button to a page for a client side only login with Google.
On Clicking the button, the user is presented with a screen like this:
There are 2 ux_mode for this button: "popup" and "redirect":
https://developers.google.com/identity/sign-in/web/reference
My question is about ux_mode=popup specifically, where the originating page doesn't change, and all the login flow is handled in a separate popup window.
Imagine a good app is published. It seems like an attacker could clone the app, present it to a user. The user thinking it's good app would login and the attacker would have a way to grab a valid token from the user for good app.
Now I understand that in that mode (popup), the IDP (Google) will reject anything that doesn't come from an Origin that is not part of the explicit list of redirect URIs set in the configuration of the project.
But is that the only thing that prevents this? I have read again and again that one should not rely on CORS for the security. Also I'm not sure but it seems that it can be circumvented with a little bit of crafting.
Is there another aspect of the security of this login flow I am missing?
I do not know google implementation but from OAuth 2 point of view:
1/ "The user thinking it's good app" user should check the address bar and a green lock in his browser. It is considered as a users responsibility.
2/ you registered redirect uris which are checked when client is trying to get access token. So google will reject to generate and redirect users browser to malicious app with the token.
3/ browser will reject any communication between popup window and other webpages since they are not same origin. This is called same origin policy and is considered as important security feature of a browser.
In general: app location/uri/origin/domain (as you want) is what identifys your app and security is based on that.
Hope it helped.
I visit an app that uses oauth social login
I choose say gmail; I get sent to gmail site
I log in to gmail and then get sent back to the app
When done with the app I log out
After step 4, even if I close the browser and open anew, visiting gmail opens my account straight away without prompting for a password. Keep in mind, I never let browsers save my password neither do I ever tick “remember me”
I’m not sure the average user will remember to visit gmail separately to log out; this would be disastrous on a public computer.
My question:
Is this a design flaw of oauth2 or is it an implementation flaw with the app in step 1 or is it an implementation flaw with google-login? Or is it technically impossible for the app in step 1 to log out of the social identity provider (in which case it’s not a flaw at all.)
The OpenID Connect core spec and the session management spec defines ways to both:
Sign the user out of an identity provider (link)
And force user re-authentication with the OP after a maximum
authentication age (max_age) has elapsed since last user
authentication. (link)
Trouble is I'm not sure if Google implement these things see this
I've tagged your question with OpenID Connect as authentication is not an OAuth2.0 concern.
I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.
I would like to know the best way of implementing automatic login to my web site. What I mean by automatic is this:
I've already signed into Google. I now go to my web site and its login page. Instead of clicking on the link to login with Google I would like the web app to detect that I'm already logged into Google and bypass the whole login page.
1) Would I use the DotNetOpenAuth.OpenId.RelyingParty.OpenIdAjaxRelyingParty.HttpApplicationStore to get associations?
2) Or do I need to look at cookies.
To your "1) Associations" guess, no. Associations that the RP may already have with Google are irrelevant to who the user is at the browser or whether they're logged into Google. Your "2) cookies" won't work either because browser isolate Google's cookies from those of your RP so you have no insight into that.
Hbas was right. I think Auto Login user to website when user is logged in to FB or google - DotNetOpenAuth has the answer to your question.
Distant memory suggests that Google had a way to disclosing to an RP that the user was logged into a Google account (with no way to identify which user or auto-login that user) with the idea being that the RP could then promote the "login with Google" button since you know the user has a Google account. However that wasn't well advertised (privacy concerns probably) and I can't find any info on it at the moment.
Ok this is something weird. I got authlogic-oid installed in my rails app today. Everything works perfectly fine but for one small nuisance.
This is what i did:
I first register with my google openid. Successful login, redirection and my email, along with my correct openid is stored in my database. I am happy that everything worked fine!
Now when i logout, my rails app as usual destroys the session and redirects me back to my root url where i can login again. Now if i try to login it still remembers my last login id. Not a big issue as i can always "Sign in as a different user" but i am wondering if there is anyway to not only logout from my app but also logout from google.
I noticed the same with stack overflow's openid authentication system.
Why am i so bothered about this, you may ask. But is it not a bad idea if your web apps end user, who happens to be in a cyber cafe, thinks he has logged out from your app and hence from his google account only to realize later that his google account had got hacked by some unworthy loser who just happened to notice that the one before him had not logged out from google and say.. changed his password!!
Should i be paranoid? Isn't this a major security lapse while implementing the openid spec? Probably today someone can give me a workaround for this issue and the question is solved for me. But what about the others who have implemented openid in their apps and not implemented a workaround?
If this is such a big issue to you, do not use OpenID, or display a DHTML popup after a successful log out reminding the users that their session is still valid on their OpenID provider.
As for Google's OpenID, what you can probably do is redirect users through the following URL after
http://www.google.com/accounts/ClearSID?continue=http%3A%2F%2Fwww.google.com%2Faccounts%2FLogout%3Fcontinue%3Dhttp%3A%2F%2Fwww.google.com%2F
Afaik, there is no way you can log the user out of their account in another system. Your app is supposed to be responsible only for it's own business. As a user, I'd be very surprised if a website using openid could log me out of my google account.
Yes, there is a scenario that a user can assume that they are logged out of google because they logged out on your site but that would (and should) be their own fault.