I am implementing gigya to authorise users from facebook, twitter, linkedin and gmail. Everthing works great as I need very little information. I am using socialize logout to logout users, but It does not work as desired, It logs out of the hosted site but not the service provider.
Is there any option that I might have overlooked that logs out users from the service providers? I using facebook, twitter, linkedin and google.
I appreciate any help.
Thanks,
Nick
Nick,
You can do this for Facebook by configuring a domain alias (CNAME):
http://wiki.gigya.com/035_Socialize_Setup/020_Facebook_Settings
This only applies to Facebook. For other service providers (twitter, google, etc), users will remain logged in.
I suspect the functionality will evolve as this issue receives more attention. For now, perhaps your site logout process should remind users that they're still logged in to (xyz) provider.
The answer is correct, so my comments are in addition to his.
The behavior you see is correct. Gigya is essentially a proxy for user connectivity and, therefore, represents a session to the social network for the site through which the user connected. However, the session with the social network provider is distinct as well, so Gigya does not presume that it owns the user's absolute social connection. As a best practice, Gigya recommends that your site/application alert the user to sign out from each network to which they are connected.
Although facebook provides a mechanism for logging the user out from facebook (as described in the prior answer), other social network connections should be terminated by the user. This is especially important for public/shared computers. To provide additional integrity Gigya also provides a setting called 'sessionExpiration' for connect/login that determines the longevity of the session.
Related
Edit respose to #cody salas
Following on from your sensible and detailed break down: -
Require Username:
Yes this seems well understood. The RP prompts for username/other-id and finds all credentials that are offered up in an array to the authenticator. Peachy!
Usernameless:
I need the "nuance" you refer to please. What (if any) filter(s) is applied to the returned credentials?
Global scope === Windows Hello User
Google login(s)
Other App logins
My Windows Hello Identity does NOT work with my Yubikey so I can't test :-(
Shared Accounts:
Ok, forget about the Beatles analogy, let's imagine one user (Our ex-PM :-) with multiple identities. ScoMo-Treasury, ScoMo-Health, ScoMo-Resources etc. What does a wildcard GET return?
End Edit 1
UA Credential Safe interogation.
Scenario:
Tri-Bank has 1 or more registered users from this device (My Windows Hello PC "Bad Boy").
There is no active session or ambient user to the RP (sub)domain. (Seeing local/session storage deprecated but all cookies also expired)
I simply cannot see a usernameless login interaction possibility
I will investigate that UPVA is deterministic on multi-user device but the spec is not only non-canonical, it seems to be off in fairy land :-(
WRT: -
Authentication WebAuthn-3 and Authentication WebAuthn-2
Please expand on point .2
The script asks the client for an Authentication Assertion, providing as much information as possible to narrow the choice of acceptable credentials for the user. This can be obtained from the data that was stored locally after registration, or by other means such as prompting the user for a username.
Which spec can we refer to (CTAP-10?) that will enlighten us to what is returned to a GET call with an empty "allowCredentials"?
How can the RP refine the user selection granularirty without a .GET that either identifies a single user or returns new Error("non-deterministic");
Does no one else see this as pivitol?
If we always have to ask for username please just say "We always have to identify username first!"
Otherwise could the user be prompted for we have Ringo, and Paul registered; which one do you want :-(
And yes, I know Paul can't login to Ringo's account without his thumb. I'm alluding to the unacceptable disclosure of Ringo's financial activity to Paul. Probably not a big deal unless it was John :-)
Please explain the FIDO2 versus OAUTH2.0 philisophical diversions pros/cons here!
OAUTH2.0 :- Would you like to continue as dicky#gmail.com? Done! no password, biometric, PIN, blah, blah, blah, pre-authenticated and trusted
FIDO2 :- I've got a UPVA that I'll probably have to test you on or a number Authentication methods for a number of users that I'll get you to pick from
Sounds about right???
Let's break this problem down into three different sections: Requiring a username, usernameless logins, and shared accounts
Requiring a username
Using an identifier is the only way to narrow down which authenticators are acceptable for an auth session. Note the use of identifier. The spec calls out username as it's extremely common, and familiar to users, but another mechanism can be used as an identifier if your environment/requirements allows for it.
Also keep in mind that this flow works well for users who are using an authenticator or ecosystem that does NOT support discoverable credentials.
I have some development guidance here if you wish to see some expanded code samples.
This won't entirely solve your problem if you are using a shared Windows Hello account. All John has to do is type the identifier "Paul", type in the PIN/Fingerprint, and have access. Overall you don't want to share authenticators, but I'll touch on that later in this comment.
Usernameless login
Remember this login flow will only work for users in an ecosystem that supports discoverable credentials. You've mentioned Windows Hello so you are in good hands. In this flow a relying party sends an empty allowCredentials list because it has no idea who is triggering the auth session. The relying party is essentially saying "send over a credential, and I'll attempt to validate it". There's more nuance to this statement, especially depending on the identity provider you are using, but that's the overall gist.
Usernameless can be broken down further depending on if you're using a security key, or platform authenticator. But during the GET() ceremony all credentials tied to your current origin will be shown depending on the authenticator that you activate. So if you fingerprint into Windows Hello, all the credentials for the current origin tied into the single Windows Hello account will be shown. If you activate your security key, all the credentials on the device for the current origin will be shown that exist on the device.
Shared accounts/workstations
So we'll continue with your Beatles example above. They can all share one computer, but this is where you need to question if they should be sharing the same Windows Hello account. If you register a credential using the Windows Hello authenticator, then anyone with the PIN/Fingerprint to that account will be able to leverage credentials on the account + device combo.
At the end of the day this will depend on how many accounts are tied to your workstation.
If you are adamant about the Beatles all sharing one Windows Hello account, on one workstation, then maybe they need separate personal authenticators, like a security key. That way no matter who is using the shared account, they still have independent credentials (unless Ringo decides to register Windows Hello, rather than his security key)
Otherwise, if each Beatle has their own Windows Hello account, they could log out/login in whenever one of the lads needs to check their bank account. In this case they will only be shown the credentials tied to their specific Windows Hello account
Hope this helps
Update 8/22
Glad my responses are helping so far - see below for answers to your additional follow-ups
Usernameless nuance
When I say nuance, I’m mostly referring to the not “one size fits all” of identity/auth providers. I can give you the code to my project using Cognito, but if you’re using Azure AD then there might be differences in the parameters that you pass to your RP. MOST of the code and logic will look the same, but it’s the small differences that might require more/less data.
For instance, let’s say that both Identity providers A and B support WebAuthn, and both will support discoverable credentials/usernamless login. But imagine that A requires that you call to its API noting the user's identifier, and B can derive the identifier from the get() response. They both accomplish the same task, but require slight modifications to the implementation
Shared accounts
I ran a test on my Windows machine (Windows 10, Windows Hello consumer). I created a Discoverable credential on account A using Windows Hello. I signed out, and logged in as account B using Windows Hello. I attempted to login to the same website, but I was unable to use the credential created by account A as account B.
So if your PM creates a credential as ScoMo-Trasury, they won’t be able to use the same credential as ScoMo-Health.
The wildcard get() method will only return the credentials for the account currently logged into Windows.
I am using firebase for a website, where users can sign in with their microsoft accounts via OAuth 2.0:
import {getAuth, signInWithRedirect, OAuthProvider} from "firebase/auth";
(...)
const provider = new OAuthProvider('microsoft.com');
const auth = getAuth();
signInWithRedirect(auth, provider);
It prompts the Microsoft Single Sign-on with a redirection work-flow.
The authentification works nice with firebase, except one detail:
When I sign in with the Microsoft account in the browser for the webapplication, I am also signed in to my complete Office 365 account in the background and other potential microsoft sites.
So if I open a new tab and go to the my Outlook 365 online mail, then I am already logged in since I logged into my webapplication. If I happen to forget to log out from the webapplication, my entire mailbox, calendar with all the microsoft account information are exposed.
I have looked through all the pages and settings in the Azure Portal where I set up application/tenant id's, looked at Scopes and looked at OAuth 2.0 parameters from the Mirosoft documentation,but I can't find anything about this issue.
Single sign-on is originally made as a convenience for the user, but in my case I would like to prevent it as a security measure.
How can I limit the microsoft sign-in to only authenticate in the webapp/firebase project, and nothing else?
The simple answer is - you can't do that.
SSO is exactly what it means - Single Sign-On. The user logs in once and can use different apps without the need of authenticating again. You ask Microsoft to verify the identity of the user for you. Microsoft logs the user in and gives you back the answer. But it means, that on this browser the user will be able to use other Microsoft services as they already verified their identity.
The only thing you can do is to inform your users about the security risks and tell them to make sure to log out at the end of their work (you can then log them out at Microsoft as well).
If MS supports backchannel initiated log out, then you can try to implement some action that will check if your user's session is still active, and if not, then initiate a logout at MS. I don't know if they support it though.
I'm implementing Auth0 in my SPA app, one of the requeriments is to have a custom UI, that also implies that i cannot use redirects to the Universal Login Page of Auth0.
After reading throught the Auth0 website, i found the Resource Owner grant type, which seems to solve my problem to handle a login directly using Auth0 API.
Is there any drawbacks of using this grant type?? (I read that is not very recommended, but i wanna hear opnions about this)
Also, is there any alternative to this grant type?? I mean, i'm stuck with this solution if Biz doesn't want redirections?? Thanks.
Resource Owner Password Grant
This can sometimes be a useful 'bridging solution', but it has some disadvantages as summarised in this article from a couple of years ago. These are perhaps the main downsides:
Single Sign On across apps won't work
Federated login options won't work (Integrated Windows / 2 Factor)
Security reviews may perform less well
Redirecting for Logins
It is very standard to redirect users to login, which signifies that you are externalising security to an expert provider. Most systems do this, including Gmail and Office 365:
You start at mail.google.com
For logins you are redirected to accounts.google.com
You then return to mail.google.com
My blog page shows the login redirect user experience for Web / Desktop / Mobile apps and there is an SPA there which you can run.
Of course, if your app is well coded there should be no down side to redirects. Eg the app should maintain the user location within your SPA, and also any data the user is editing.
I am working with a research group that needs to collect Facebook post data for a group of participants over the course of a few months. The goal is let the participants authorize us to collect this information via facebook, and when they post to Facebook, send that information to a secured server.
After reading the Facebook documentation, I'm mostly just confused about how to provide a mechanism for the user to agree to the terms of collecting his/her data. I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
You most likely won't get this approved in review anyway.
Permissions must, for the most part, be used to provide a direct benefit to the in-app user experience; collecting data for analytical measures only is explicitly mentioned as a not allowed use case. Whether the users would agree is not relevant here.
For example, user_posts permission, has "non-visible use of this data such as sentiment analysis or guarding against spam bots" marked with a red "X" for nope.
So the only way of getting your app to request the necessary permission(s) from users, would be to add them as testers to the app via app dashboard/API. Anyone with a role in the app which can be asked for any permission, reviewed or not. Those users would however have to have their accounts verified (mobile/text, credit card) and sign up as a "developer" on the FB platform, before your app could send them requests to become testers.
You'd be flying under the radar with that, so to speak. Facebook offers this "loophole" mainly for the purpose of letting developers test and develop their apps properly, before review. It is also explicitly mentioned in the app development FAQ as a way around the need for review, for specific use cases such as wanting to get your blog posts published to your own FB page automatically. It would not cover what you are trying to do so, but it will likely "work" as long as none of your test users specifically raises a complaint with Facebook ...
Not sure if there is any published limit on the number of test users that can be added to an app, people have asked about that in the past, but AFAIK none is documented or otherwise published by Facebook. If there is one, and it is not completely stopping this approach dead in it's tracks (say, a few hundred per app rather than, five), you could use multiple app ids, if you don't need to relate data between user accounts too much - because the app-scoped user ids will be different per app id, so that could making connections between friends that are in different "app-id test groups" etc. difficult. Or you might have to refer to other, less reliable measures of uniquely identifying them, such as email or profile name.
I want to create a web widget that will display information from my site.
The widget will be included in the client's website HTML using JavaScript, and should only be usable for my clients -- web sites that were registered at my site.
The information in the widget should be specific to the user who is currently visiting the client's site.
So, I need to authenticate both the client (website owner) and the resource owner (website visitor). This seems to map nicely to OAuth 2.0, but I couldn't find a complete example or explanation for such an implementation.
Any resources or pointers to such information will be appreciated.
Update: I've stumbled upon this article, which provides an outline for an approach that uses OAuth. However, it is not detailed enough for me to really understand how to use this with OAuth 2.
There are many large organizations that have done this, and I'm sad to see no other answers for this question since it's such an important web pattern.
I'm going to presume that you are not rolling your own OAuth 2.0 provider from scratch, if you are - well done otherwise you should be using something kickass like Doorkeeper to do this for you.
Now, in OAuth 2.0 you have the following entities:
Users registered on your website
Applications registered on your website (who subscribe to your oauth2)
User Permissions which is a list of Applications that a user has 'allowed'
Developer (who is consuming your auth API / widgets and building an Application)
The first thing to note is you must have a domain name associated with each Application. So if a developer registers for a API token / secret on your website, the Application he creates is mapped to a unique domain.
Now, I presume that the flow for an application to authenticate users via your website is already clear. That being said, you don't need to do much for this to work.
When an Application sends the user to your website (in order to sign in) you place a session cookie on the user's computer. Lets call this "Cookie-X".
Now the user is authenticated by your website and goes back to the Application. There we want to show a custom widget with information pertaining to that user.
The developer will be need to copy paste some code into this app.
The flow is like this:
The code will contain a url to your website with his Application ID (not secret) which he got when registering his application on your website.
When that code runs, it will ping your website with his appId. You need to check that AppID with your database, and additionally check that the referrer url is from the same domain as that which is registered in your website for that AppID. Edit: Alternatively or additionally, the code can check for document.domain and include it in the ping to your website, allowing you to verify that the request has come from the domain that has registered with the given AppID.
If that is correct, you reply back with some JS code.
Your JS code looks for the session cookie your website had set when the user had signed in. If that cookie is found, it pings back to your website with the session and your website responds with the custom view content.
Edit: as rightfully mentioned in a comment, the cookie should be HttpOnly to safeguard against common XSS attacks.
Additional Notes
The reasons this is a secure approach:
The AppId and domain name are a good enough combination to verify that other people are not fetching this information. Even thou the appId is visible in the applications html source, the domain name would have to be spoofed by anyone attempting to use someone else's AppID.
Presuming someone takes an AppID which is not his, and writes code to spoof the domain name of the referrer when requesting for your widget, he still won't be able to see any information. Since you are showing user specific information, the widget will only render if your website can find the session cookie it placed on the users browser which can't really be spoofed. There are ways around like session-hijacking, etc. But I think that's beyond the scope of this question.
Other Methods
Just by looking at Facebook's Social Plugins, you can tell that there are other options.
For example, one might be to use an Iframe. If you ask the developer to add an Iframe to his application, you can even reduce a few of the steps mentioned above. But you will have to add JS along with it (outside the iframe) to grab the correct domain, etc. And ofcourse from an accessibility and interface standpoint I'm not very found of Iframes.