Quick short background
I'm building a standalone web app using Angular JS 1.5. This web app makes usage of a API built with Laravel 5.2 (no sessions, just JWT Tokens and REST calls). Using Laravel-Socialite, I managed to make the following structure. It works nice and all, but we kind of have a overload of redirects.
The Button calls a /facebook route that invokes the Socialite magic box which leads to redirect to the Facebook Page for authorization.
After I achieved this, I noticed that a Facebook Login LOOKS a lot more of a front-end task than a back-end one. It's just about helping the user quickly sign up using Facebok available data or sign in without a password.
The Problem
Socialite makes usage of my Facebook App Secret, not to mention that it's a known environment server operation, while a Front-end we may never trust. Here is what I managed to achieve using JavaScript SDK (with AngularJS).
On a first-time access, I can get that information and sign up the user and automatically sign him in. But the problem lies on a existing user.
In this case, technically I can use the response.email information that Facebook gave me and make a request to my API to make a login without a password. But can I really do it? How do I make sure the request is being made because Facebook authorized it? After Facebook replies to my Web App, what is a secure way to tell my server that it can issue a JWT Token to that email?
Conclusion
Do I make the three-step redirection (Web App → Server API → Facebook) to sign in / authenticate a user using Facebook or is there something I'm missing here that could be the key to transferring this responsibility to the front-end (and avoiding a 3-step-redirection)?
Related
I am trying to integrate docusign with a React Native app I am building. My desired workflow is to have the user launch a remote signing envelope based on a template.
From the Node JS examples, eg009 seems to be the end result I am after. However, I am wanting to complete this with Axios/Fetch and Javascript.
My intended flow is to have the user enter in their name and email, and their spouses name and email. From there they press a submit button which sends the API call, and that is the extent of what the app does.
I am wanting the API call to then start the template flow, sending a document to sign via email to both that were entered into the app. I want the users to authorize themselves from the email, not the app. After both parties have signed, I want it sent to a third static email.
I do not want the users to have to authorize inside the app or be redirected anywhere. It seems a JWT would be best.
Does this seem possible? How would you suggest going about this?
I appreciate the help!
Looks like the JWT grant flow is the right fit for you here. Please see this article for more details: https://developers.docusign.com/platform/auth
There's no good solution for running DocuSign API calls from client as a result of CORS limitations.
Larry has some blog posts on this topic - https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-2
You could use something like AWS lambda which is not a server per-se, but gives you server capabilities without the hassle of a server.
Check also the latest blog by Larry on this topic which superficially covers using React for single-page apps.
I have developed several web applications with the own login forms/logic etc. I would like to simplify these by creating a single dedicated web app to handle all the login logic using FirebaseUI. The way I imagine this working is when the user needs to login with one of my apps they are redirected to my login web app. The user supplies their credentials and if successful the login app redirects back to the original app with data to confirm whether the login was successful.
If this is possible I shouldn't have to repeat the login logic in my other web applications and any changes to login code are only required in my login app. I'm not sure if such an approach is possible, however, or how I could securely and safely let each web app determine that the user has successfully logged in. Can anyone offer advice on how to implement this or point to examples where this has been done already?
You might be looking for single sign-on.
Google does something similar. Every time you login you're redirected to accounts.google.com, and after that you're redirected to your app.
You're right in saying that it's trickier than it appears on first sight though. Most web login systems are based around cookies and the whole client-server process around them. Cookies are set per domain. If all your webapps are on the same domain or subdomains of a single domain, you should be OK to go with this approach and get the results you want. If not, you're going to need some extra work to get code from different domains to speak with each other and make everything possible.
In general, if designing a login system from scratch is considered a big endevour, designing a single sign-on system is an order of magnitude harder. OWASP had this to say about them in 2011.
I'm building a PHP web application, something like "Auction", I want to let the user to sign in using their facebook accounts.
I started using javascript SDK, I've built the first page in which I asked the user to login using facebook, after the authentication is made, the page refreshes and according to some cookies I stored after the authentication, the page layout and elements change.
I want to save the login status in such a way the server knows if the user is authenticated or not, I know I can same the appropriate cookies to give the server these information, so do I need the PHP SDK in the future? Is it better if the retrieving of user info done in PHP at server side? what advantages I get from using the PHP SDK rather than using the javascript?
I'm sill in the very beginning of the development process, and I'm not sure if I'm going the right way to use the javascript SDK alone! any help concerning this dilemma will be appreciated.
thanks
I remember all the stuff from the signed request for canvas apps: http://developers.facebook.com/docs/authentication/signed_request/
Now I'm using the JS SDK (FB.login() method), which already gives you the auth token et al. as well as a signed request. Instead of the info that a canvas app's signed request gets, I get just:
{"algorithm"=>"HMAC-SHA256", "code"=>"2.AQAdX5Zl5gY-Z_D7.3600.1322193600.1-XXXXX|HmarTBK09MSiB0o76cLgaTUd4y4", "issued_at"=>1322188281, "user_id"=>"XXXXXX"}
So what confuses me is: what's the point of the JS SDK's signed_request? I already have all the info I need from just the login reply.
when your app user comes to your https://apps.facebook.com/myapp he comes with signed_request.
Then you serve your user to your landing page. In that landing page fb jsdk loads and writes to cookies to browser.
Then when user comes to your server he comes with these cookies. So writing cookies are not your job but fb jsdk's job.
Then your server reads those cookies and process further actions.
Additional info
While surfing at github, I found
This client library is designed to support the Facebook Graph API and
the official Facebook JavaScript SDK, which is the canonical way to
implement Facebook authentication.
and
If you are using the module within a web application with the
JavaScript SDK, you can also use the module to use Facebook for login,
parsing the cookie set by the JavaScript SDK for logged in users
Taken from here.
There can be extra information provided in signed_request that isn't provided in the login response.
For example, if you need to check if a user is a fan of the page housing the app, this information is provided in signed_request. This can be injected into the page at load time by the server if the user is authenticated at that point, however if you are using an ajax authentication and signed_request were not provided in the login response, you wouldn't be able to check the fan status.
When I use Facebook's JS SDK to authenticate my app (using FB.init method) all I need is my App ID. It does not require my app secret and/or app key.
However when I used PHP SDK, it required my app secret (atleast the example I used to learn used the app ID and app secret both).
Is it secure and recommended to use the JS SDK for authentication ? How really does the authentication flow happen with the JS SDK ?
Thanks,
Vineet
I'm looking into how secure the authentication is also - I think things have changed since you asked this q, so perhaps this information was not correct when you asked.
The new version of the JS SDK uses OAuth 2.0. This is well documented - check out the OAuth 2.0 site for details.
Regarding the issue of whether the SDK needs the app secret - I'm having a little bit of confusion relating to this. On the app server side, the libraries indicate that the JS SDK signs the cookies using the app secret (see the function get_user_from_cookie in the facebook-python sdk) - however, it's completely unclear to me how the JS SDK can know the app secret. I'm guessing that it can obtain it dynamically from FB when it talks to FB directly in the authentication process, but I'm not sure.
(Edit: I think that the JS SDK gets the cookie signed with the app secret directly from FB - the JS SDK never knows the app secret).
Not fully answering your q, but perhaps shedding a little more light on how this works.
Another issue to be wary of is not to use the FB user object you get from the client for anything on the server side. This is because it would be really easy for someone make a script which instead of calling fb.api '/me' would send a "fake" JSON user object with another users ID to your app. If you're doing any kind of server side processing of the user then you really need to do some kind of server side authentication as well I think.
It's NOT safe, this is why you have the "Verify Fields" and "Not Verifying the Signature" paragraphs in the Advanced Registration document:
When you request facebook data, we
verify the form fields before
packaging them up in the
signed_request. This lets you assume
that all the data is genuine and saves
you from having to verify things. The
one problem that could arise, is a
smart attacker could change the form
fields and submit them to you, thereby
giving you unverified data.
Read that document for more information, I've also wrote a tutorial (an introduction about the plugin) and showed how to handle the fields attribute coming from client-side.