On a website I have implemented the login using OpenID (based on StackOverflow).
But I can't seem to logout.
On my host I can logout but when the user tries to login again (especially with google) the authentication goes through without requiring the user to type in name and password.
How can I indicate to the OpenID Provider that a user is no longer logged into the site?
OpenID authenticates users to your site, when then starts a session on your site. You destroy or invalidate your site's session separately from the user's session with their OpenID provider.
User visits joewidgets.com > User logs in with OpenID (with a new or existing provider session) > ... User clicks logout > joewidgets.com destroys/invalidates the session.
If the user has their OpenID provider keep them logged in, and your system automatically checks, then it will create a new local session. (Un)fortunately, you don't/can't worry about what the user does or does not do at their provider, which is a pro/con of OpenID.
There is an argument at Social Lipstick which calls for "Single Sign-Out", but OpenID does not currently provide this function.
This is called Single Logout or Single Sign-Out, which OpenID doesn't support. In my opinion, SSO without logout is a big security hole. Logging out a single site doesn't mean much if others can just get in with a few clicks.
For now, we have to remember the provider. If it's someone we know, we trigger the logout process for them. For Google, the URL is,
https://www.google.com/accounts/Logout
The logout flow is ugly but it does the job.
That's generally something handled by the OpenID provider - for instance, if the user remains logged into their Google account and checked the box to "remember" the OpenID authorization for your particular site, then the provider will transparently log them in and redirect them back without displaying the login prompt.
"It's a feature not a bug"
The id provider can choose to keep the user authorized for the provider through cookies, and further can choose not to re prompt the user about sharing the same information that was shared previously (with a prompt). So when the user on Site A, asked to be authorized through Site B, and got redirected, Site B first asked for the user to authenticate him or her self. Then Site B asked if it should share any information (and sometimes which information) with Site A. At this point it will also customarily ask if you want to automatically share this same information in the future. Some providers will assume yes, some no, some won't ask. Site B then redirects to Site A and shares the information, you're now logged in.
If Site A makes a second redirection to Site B to request a login, Site B might
1) Already have a cookie that authenticates the current user of Site B.
2) Already have a record of what information is acceptable to share with Site B.
3) Automatically share this information through a redirect without pausing to prompt the user at all.
This is a feature centered around convenience.
Related
In the latest version of our SAAS product, we are designing it to allow our customers to deploy multiple instances of the software.
We require the sign up and login to be tightly integrated into the primary domain - the "sells the product to new customers" website PrimaryDomain.com which features "Sign Up" and "Login" forms that use jQuery/AJAX to give responsive feedback on data submission.
When a customer successfully logs in, they are to be presented with a list of all their installed instances of our product. All installed instances of our product can be hosted across dozens of domains, but to keep this question simple, they are hosted on [subdomain].SecondaryDomain.com (code + database).
Every installed instance also features an admin panel which currently customers need to manually login to each individual instance as required.
We want the customer to be able to click on 'view admin panel' next to any of their installed instances and automatically be logged in on [subdomain].SecondaryDomain since they were logged in on PrimaryDomain.com.
SecondaryDomain.com naturally doesnt have access to the cookies or session variables of PrimaryDomain.com so what is the best way to allow SecondaryDomain.com to authorise?
We have considered a few different options, such as;
Researching some clever way that the domains can share cookie/session data?
Generate a token that is passed with the url when clicking 'view admin panel' to the second domain. The token is unique to the userid plus subdomain (such as an md5 hash) and then validating it on the receiving end.
Recording a one-time-use token into the database and sending with the url and having SecondaryDomain.com connect to PrimaryDomain.com's database to verify the one-time-use token and set appropriate session and cookie variables.
The one-time-use token seems like the right approach, but i havent been able to find any concrete answers on (a) if this is even the RIGHT approach, and (b) what the security implications are around it?
I recommend SAML for this case. SAML requires you to have an identity provider (IdP) and service providers (SP). The user will login to the IdP and present the token to any SP visited. The SPs need to be configured to assert the token against the IdP. You probably want to look into Auth0's SAML SSO offering for more information, but there are other providers out there that do the same thing.
I created a web app that allows users to connect their google calendar using OAuth2. And so far everything is working the way I've wanted it to be. Now my concern is, when a user clicks the link to authenticate his account, I want it to forcefully redirect to the google login page. Right now, when he clicks the link and his google account has an on-going session in that specific browser, the login page no longer appears. Is there a way to do that? Thanks.
If you set the parameter approval_prompt to force, you should be able to forcefully show the auth screen every time. More details about this parameter are documented here.
the only way to do that is to force a full logout from that client (browser, app, etc). You can do that by using:
https://www.google.com/accounts/Logout?continue=https://appengine.google.com/_ah/logout?continue= and add the redirect as "continue" parameter.
This will logout from everywhere so the user might not be happy if he/she didn't do that on purpose.
I would go with asking for permissions again if you want to make the users "feel" like they are actually login into your app again (i assume that why you want this approach).
Google also has a "switch user" option, but I haven't use it and it's really hard to know if the user will be asked for user and pass or the user will be automatically authenticated because he/she is already logged in another tab in the browser.
I've managed to have an user sign in for my website through Facebook. It works this way:
User goes to my website and chooses to sign in with Facebook
Users goes to Facebook to authorize my app
If the app is authorized, the user comes back to my website and gets registered into my database
The user remains logged in via a cookie set by my website
I store these pieces of information from Facebook: username, email and ID.
What should happen if:
User logs out from Facebook and is still logged into my website? I still have that cookie and session that lets the user remain online, so even if the user isn't logged on Facebook, my users still can benefit from my website. Is this behavior normal or should it be avoided?
An user removes my Facebook App from his authorized apps list? The user is now part of my database, but the user removed the app from his account. How should I deal with this? How can I check if the App->Website connections are still valid for that user? If an user removed the app from his account, should I also remove him from my database? If yes, again, how do I make that check?
There are quite a few other things that are puzzling me and I think I should dedicate another question to those later on.
I'm using Facebook PHP SDK for all these tasks.
P.S: I only use Facebook as an authentication method for my website, nothing more.
To answer your question here are few things we do for the facebook connect
If user choose to create an account with the FB connect, we grab the
details like firstname,lastname, email, fb_userid and then save to
our database.
If the same user when comes user has to click on the FB login button and we check in our database if the API return fb_userid is in
our database and process the login and give access to the user pages.
So ideally we never store the fb_userid in the cookie and next time if the user comes just do the autologin.
Now what if user remove the app from FB, since we do not allow auto login by cookie saved data the user must click on the login button and then re-authorized the app. Since the fb_userid is already in our db, we detect the user after giving permission and let them login.
We have one advantage in our case , i.e. our web app requires monthly subscription so user has to pay for that. So usually people who do want to continue they come to our web site and cancel the account, we then remove the user info and that way fb_userid is also removed at our end. This makes us not to worry what if user remove the app from their FB, since if someone has to cancel they will do it from our website since they are in monthly recurrent billing.
I suppose in your case its not as above point, so you can do the following without violating any terms and conditions
Do not store the session in cookie and make user login with FB button
each time they come to your website. Also make a small note on your
website next to FB login button as "what is this ?" as may be a tool
tip and mention that the website will store the users fb_userid and
this will not be shared with any 3rd party.
Also mention that in case they remove the app from their facebook the id will be still there in our database and create
a cancel account page where user can cancel the account, but that
needs the user to be logged in. Once they cancel the account remove
the FB id from your DB.
Finally I dont think any API call could be used to see if the user has removed the app for offline users, but people who have logged to your site using the FB connect different permissions could be checked as
$permissions = $facebook->api( "/me/permissions" );
If the app requires Facebook, then you need to test the cases you mention and generate appropriate error messages. Beyond that, you just provide obvious ways for your user to clean up, like a working uninstall command.
I'm new to opeid, so forgive if the question is dump. I'm developing a system (on PHP) to unify login through various openid-providers. There should be several methods (login, check if user is logined and etc).
The problems is that the system will be used by flash. And I don't know how to perform login without redirect. Here's my question: if a user is already logined on open-id provider (or uses provider like myopenid which don't need password) and has confirmed that he allows to use his personal info, is it possible to login without redirect (to login page on openid provider). An example will be great!
Will be grateful for any thoughts!!!
You should perform an immediate request to the provider, i.e. by setting the parameter openid.mode to checkid_immediate. The provider MUST respond with a respons whether the authentication was succesfull or not. If the authentication was not succesfull, you should still perform the redirect to allow the user to authenticate.
I've set up a facebook login for my site, using the faceboko php-sdk example.php method. It's working fine, but I want a user who has already allowed my site once to be automatically logged into my site, if they're logged in facebook.
Currently, if a user who has previously 'allowed' my application visits my site while logged in with facebook, they need to click login with facebook, then they are redirected and logged-in. Even though after that click, they don't need to provide any credentials or anything. Thus I would just like this step to be removed and for a user to be automatically logged in.
I hope that makes sense. Thanks
This is discussed on their site.
http://developers.facebook.com/docs/guides/web/#login
Facebook Platform uses OAuth 2.0 for
authentication and authorization.
While you can add login to your site
using OAuth 2.0 directly (see our
Authentication Overview), the open
source JavaScript SDK is the simplest
way to use Facebook for login.
[...]
In order to log the user into your
site, three things need to happen.
First, Facebook needs to authenticate
the user. This ensures that the user
is who they say they are. Second,
Facebook needs to authenticate your
website. This ensures that the user is
giving their information to your site
and not someone else. Lastly, the user
must explicitly authorize your website
to access their information. This
ensures that the user knows exactly
what data they are disclosing to your
site.
http://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus/
By testing for the presence of the
session object within the response
object, you can be sure the user is
known to your application and you can
begin to make further calls to the
Facebook APIs. If the session object
is not present, the user is either not
logged into Facebook, or has not
authorized your application.
http://developers.facebook.com/docs/authentication/
Check the client side flow section to see when you get the authentication token you need to be passing around.
If the user is already logged in, we
validate the login cookie that we have
stored on the user's browser,
authenticating the user. If the user
is not logged in, they are prompted to
enter their credentials