I'm building a widget that can be placed on a various sites, and will have users be able to log in via facebook connect to accounts on the widget's parent site. I was going to use the Facebook JS SDK to do this, but the widget will likely be placed on sites that already have the FB JS SDK initialized on them with a different app ID, and if I were to run code this way it could lead to a namespace problem.
The only current solution I have come up with is to do the server-side type authorization, and have a redirect-url that leads back to the current page in which the widget is hosted and use the state paremeter to alert backbone router that the user has logged in.
The first problem I thought of is that on the facebook docs site it says
For security, the redirect_uri must have the same base domain as that specified in the App Domain property of your app's settings, or be a URL of the form https://apps.facebook.com/YOUR_APP_NAMESPACE.
How do I bring people back to the original page that the widget it hosted on after login? Is there a better approach to this problem?
you can use Server side authentication and redirect_uri to your site that will redirect to the various site
redirect_uri = https://www.mydomain.com/?r=https%3A%2F%2Fwww.somesite.me
On you server you will look of the query param r and redirect the request to r value.
You can also do your own authentication for users (when they first sign in) and store there facebook access_token on you DB, once your widget is running (under https) and you identified the user on your authentication you can send the widget client the user's access_token and work with it.
You can even create your own Simple FB-like ajax library, for most things it will be a simple get/post/put calls with access_token as a url parameter
Hopes it helps
Related
Facebook JavaScript SDK guide contains an example code to integrate Facebook login and authorization for a specific application. The only information provided to this script is the App ID.
Let's say an user authorizes my application to access his private data. Now, what prevents someone else to put a Facebook login form on his own application using my App ID and JavaScript to make it look like it came from my domain and access this user's private data?
Do browsers provide enough security on this subject?
Now, what prevents someone else to put a Facebook login form on his own application using my App ID and JavaScript to make it look like it came from my domain and access this user's private data?
Do browsers provide enough security on this subject?
Nothing to do with the browser, really. Facebook will only pass data back to a domain that's in your whitelisted set of app domains in the developer console.
When the SDK redirects user to Facebook, Facebook's servers redirects back to your site. The redirect URL is set by you in the App Settings of Facebook Developer Center. If someone steals your App Id and puts it in his site, all of his users would be redirected to your site.
I have a scenario that I think should be fairly simple, yet I'm not finding a solution and wondering if someone can point me in the right direction.
The setup:
1) SharePoint online website (user must be authenticated to see page)
2) .NET MVC Web API service endpoint (user must be authenticated to get data from the service)
Both of these authenticate using the same Azure Active Directory. The Web API has been registered in Azure AD.
The problem:
I would like to put some javascript on a SharePoint Online page (not a Sharepoint Add-in, not an AngularJS SPA) that will make an AJAX call to the Web API using the logged in user's credentials without any kind of user prompt (since this is an ajax call, the user won't see the prompt anyway).
I've tried looking into the ADAL libraries, but all the JavaScript ones I can find require the use of Angular and require the user to authenticate a second time. I've found some documentation using OAuth 2.0, but (from what I can tell) require you to get the client to authorize the Sharepoint Online page to act on their behalf - which the user will not be able to consent to because it's an AJAX call and the consent page is not displayed in the browser (and it's still doing this despite having the app already approved by an administrator in Azure AD).
It seems to me the user shouldn't have to leave the SharePoint page and shouldn't have to enter their credentials a second time. I believe there should be some way that the log-in to SharePoint Online should also be able to be used as the log-in for our in-house app.
If someone could just point me in the correct direction, I would be very much appreciate it. Thanks in advance.
Normally, if we call the resource which protected by Azure AD, we need to authorize the app via OAuth 2.0.
Were you able to put a hidden iframe in the SharePoint online page? If it is possible, then we can use the Azure AD implicit flow get the token through iframe, and we can call the REST which protected by Azure AD via the token return by iframe. To enable the implicit flow, we need to download the application manifest from Azure portal and switch ‘oauth2AllowImplicitFlow’ to true.
And if you were only developing a single tenant which doesn’t require users to consent the app. Here is the HTML code request the token from a Iframe for your reference:
<iframe width="0" height="0" id="oauthHideIframe" src="https://login.microsoftonline.com/{tenantId}/oauth2/authorize?response_type=token&client_id={Client_Id}&redirect_uri={redirect_Url}&resource={your web api app url register on the protal}"> </iframe>
And to pass the token from iframe to the parent window, we can use the window.postmessage which allow the corss-orignal communication.
I'm currently building a frontend client for my own Apigility API.
The API uses OAuth 2.0 Authentication which is working fine.
I want to create an AngularJS Landingpage to let the users authenticate by entering their credentials. Because the Client is created with JavaScript,
I shouldn't save the client_secret in the Client, correct?
I have read a lot of posts, but still haven't the right solution.
Is it correct to use the implicit grant type for this scenario?
This procedure is working, I'm being redirected to the authentication server,
after the client authorization and entering credentials, I get back to the client (authenticated).
But I don't want to get redirected to another authentication page.
Is it also possible to authenticate directly and secure on the angularJS frontend?
Thanks,
Simon
You should take a look at this post i made:
https://stackoverflow.com/a/42443878/2963703
It details how to do this using the Spotify API. Your page won't get redirected, instead a popup window will open in which the user authorizes themselves. Once they're authorized the window will close itself and in your main page you will have the access token you need.
Goal: A single page application that uses Facebook authentication to login, but does nothing with Facebook after that.
Tech: Facebook Javascript SDK, AngularJS, angular-ui, .Net Web Api
I'm creating a Single Page Application (SPA) in Javascript using AngularJS. I'm using the Facebook SDK which is working to authenticate the user; it returns me a facebook user id, an access token, token expiry time, a signed request, and some other stuff, all on the client side. I then pass this information to my service, mostly because I feel I should. After this I don't really care about Facebook. But I want to make calls to the server to load the user's data.
I could just make all requests using the facebook user id, but there would be no security because any client could just call that endpoint and pass any user id until they found a valid one.
I could use the access token on each request as well, but I still think this is a security failure; when the user first logs in and I pass it to the server, well that endpoint could also be called by any client... "LoginServer('myfakeaccesstoken', $knownUserId)
I get the feeling that I should validate the token on the server side back with facebook, and then I can safely rely on teh token on future API calls, but I'm wondering if there are any other approaches?
The Facebook documentation seems to focus too much on me wanting to make follow up calls to their graph API when I really don't care after my user is authenticated.
I know the issue of securing connexion between a JS app (let's say just 'app') and an OAuth2.0 server (let's say just 'server') is an age-old question.
However, I can not find a lot of information about the special case where the app and the server are coded by the same entity and stored at the same place (i.e. same domain, or at least, two subdomains of the same domain).
First of all, as far as the OAuth grant type is concerned, I think the right one is the Resource Owner Password Credentials Grant, since the server and the app have the same author. The issue here being that the Client ID and Client Secret are available to the user in the client. This can be dealt with either by developing a proxy on server end or by using short-life tokens and disabling CORS (if I understood correctly). Is there any other property we can take advantage of as far as security is concerned when server and app have the same author?
My second question relates to the optional use of a Facebook Login authentication (or whatever well-known app OAuth login system: Google, Twitter, etc.).
Ideally, I want users to log in using either:
My-app-related credentials (if they registered without using FB login option)
Facebook credentials (if they registered using FB login option)
The first log in method is the classical one: upon log in, are sent to the server the user credentials along with the client ID and client Secret, we get back an access token and everything works well.
I must confess I'm a bit lost with the second method: upon login, user Facebook credentials are sent to Facebook server, which responds with an access token, and my app get access to my user Facebook information (such as email address and UID). But I do not know what to do with this FB information, and especially what I should sent to my own OAuth server so that:
The user gets connected to my server
The connection is secure (i.e. no one can impersonate the user by only having to get her Facebook UID for instance).
In other terms, there should be something secret related to Facebook sent to my server but I can not figure what.
I have found the answer to my second question, so I share it here:
What should be passed on to the server is the Facebook access token, so that the server can :
make a request using Facebook PHP SDK and the given token
retrieve user data (such as Facebook UID for instance)
match it against your website user database (which should have users FB UIDs)
actually connects the user if there is a match
Step 1. and 2. can be done nicely with the helper class FacebookJavascriptLoginHelper of the FB PHP SDK. In this case, the access token is stored by Facebook Javascript SDK into a cookie that is read server-side by the FacebookJavascriptLoginHelper.