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.
Related
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)?
I want to add "login with XYZ" capability to one of my web apps. I don't need any of the advanced stuff - just logging users in with one of their existing profiles so they don't have to remember yet another login credentials set.
After some research, I found HybridAuth and hello.js.
I know Javascript as well as PHP, but I have never implemented OAUTH 2 support before.
From what I can see, I could technically imagine implementing the identification and authentification both in Javascript or in PHP.
What would you recommend I choose, and why?
Since no comment or answer really answered my question, I'll answer with the additional reading I have been doing. I hope it will help if you arrived here via your research into the same question.
Having to use your "client secret" requires an OAUTH 2 client to have some server-side code (I don't want to have my "secret" in client-side JS, do i...). Hello.js solves this via a OAUTH Proxy.
Since I prefer to minimize my dependencies on third parties in production, I'd much rather use PHP in the first place.
Therefore, I will be implementing with hybridauth for now.
I had implement some of features like "login with Facebook", here is the common pattern,which is indicated by this picture.
What you have to do is firstly redirecting user to Facebook authentication server and when user get "code" from Facebook authentication server,you can get "access token" by passing "code" to Facebook authentication server(different url). Secondly, when you have "access token", you can now get user profile by Facebook API and then save to database or other thing.
So, the differences between hello.js and HybridAuth is that hell.js uses browser (Javascript) to do things after user redirect with "code", but HybridAuth do it on server side(PHP). But they do have the same pattern which is indicated by the picture.
I used both JS and PHP versions for FB.
Using server side library you can do your business without reising suspicions. For example collecting some public info to merge duplicate accounts, storing the profile image, login attempts. Other requests you might need for your business and user experience.
I'm building client server REST application.
Client side is based on Angular while server is PHP (not that it matters much anyhow).
What I am wondering if there are any best practices, good examples of captcha implementation in this case? Captcha would be used for user registration etc.
I'm not limited to any specific libraries, only requirement is that there cannot be any calls to 3rd party servers on client side (js libraries hosted on 3rd party servers or req api key etc).
thanks
When google captcha approves one user, it provides you a token.
So imagine this scenario. A User is about to save, and uses the captcha, the captcha does its business and gives you a token, it is all that matters.
If you want to see a "tentative" flow of requests for this.
The User should pass the captcha before registering and retrieve the token that it provides in the front end.
User clicks save, you receive the captcha token in the backend as form data. You validate the token with Google via an API. If Google verifies the token as valid, you can save the user or reject if Google returns an error.
The frontend listens for success or error and what kind of error. IF error is captcha, force a retry, get a new token.
Backend receives a new token in form data and repeats step 2.
You can have a look on google-recaptcha. Its angular implementation is here
vcRecaptcha
Google's new-ish reCaptcha is pretty slick. They have several easy to understand examples and usage scenarios.
https://www.google.com/recaptcha/intro/index.html
Edit: To address your specific question of how to implement this in a RESTful application, I'd make two files. One would be a public-facing file like index.php and the other would be a back-end file that would hold the private information.
I could copy/paste my previously-written how-to here, or I could just link you to the article I wrote 2 months ago.
I am trying to create a web app using meteor. I am hoping to use the app on my college campus and I wanted to use the college's authentication service so students could login with their college email address and password. I need to query (with HTTP POST request) https://www.bowdoin.edu/apps/mobile/login.php to get a 0 indicating incorrect user info, or anything else to indicate the user can successful log in. I would like to use the meteor accounts-ui styling and login format and simply authenticate using the POST request. I also want to keep the functionality that allows users to have an id associated with their email address so any user content in the app will stay associated with that user when they log in again. I would like this to be implemented in a way that uses as much code from the accounts-base and accounts-password packages meteor has. The only unique login feature in this case is a post request compared to the Oauth typical of other services.
If you want to use Meteor's built in Accounts package, I think your college's authentication service needs to support OAuth. Per http://docs.meteor.com/#meteor_loginwithexternalservice:
Meteor.loginWithExternalService([options], [callback])
These functions initiate the login process with an external service (eg:
Facebook, Google, etc), using OAuth. When called they open a new
pop-up window that loads the provider's login page. Once the user has
logged in with the provider, the pop-up window is closed and the
Meteor client logs in to the Meteor server with the information
provided by the external service.
See that section of the docs and try to build your own accounts-bowdoin package similar to the examples (accounts-github, etc.); see https://github.com/meteor/meteor/tree/d477c8d03bb078f7e8e85dbe4b51db7ae5689573/packages/github and https://github.com/meteor/meteor/tree/d477c8d03bb078f7e8e85dbe4b51db7ae5689573/packages/accounts-github for example.
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.