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.
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 want to send notification mails to users of my community platform coded with react and firebase. I was wondering is there is a way to authenticate the user via a magic link which is contained in his or her personal notification mails.
E.g. You've got 5 new comments on your post click HERE to read them
Clicking "here" should redirect the user to the page and automatically authenticate him without having to enter their individual passwords or usernames.
Due to the cancelation of the privacy shield framework and Schrems II, you might no longer be able to store customer details in the GCP.
A solution for it can be pseudonymization.
I am running an open-source project that can help you with that.
Check out the following article for more information:
https://databunker.org/use-case/schrems-ii-compliance/
I think your question can be divided into 2 different questions.
1. How do I send notification mails to my community platform?
I have never used notification mails in Firebase, I usually use google's SMTP server directly and send a request to the server to send an email on behalf of me. So, in your case, I would search up the library on your tech stack (for me it was Go's gomail), then you can use Google's SMTP server (host:smtp.gmail.com, port:587).
2. How do I make a link that automatically authenticate your users whenever they click the link?
I feel like this is the harder question. I think you need to consider a few things:
Your links need to be short lived. Why? to prevent unauthorized brute force login attempt (this also depends on the structure of your link). However, best practices suggests that links should be short lived (less than 24 hours).
Given that links are short lived, this depends on whether the user checked their email frequently for notification from you! There's a pretty good chance that they will miss that email in the 24 hour window.
I'm pretty much against sending time sensitive notification like that through emails. But if it is something that you still want to do, it is pretty easy to create the link, the simplest way I did it was:
Generate a random uuid for a link.
Associate it to the user who will login with the link. You should save this association in a persistent data storage.
Create an endpoint for magic link, for example /magic/:link_id that takes link_id then checks what user should be logged in.
Voila! You got yourself a magic link!
Finally, you can send the link through email like the first part of the problem!
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 have a client who would like the most recent post displayed on their site (along with like and comment counts) plus a link to the actual post. Their page is public, so I can view it in a browser without being logged in. Let's just say it's Nike.
http://www.facebook.com/nike (public)
http://graph.facebook.com/nike/feed (wait, i need to authenticate to see this?)
I went through the trouble of setting up a dummy app on a dummy account, got an access_token an was able to pull what I needed using javascript(Jquery). The reason I'm doing it this way is because the client has sensitive data and other apps/sites on this server and does not want to involve their IT department to QA my code.
Before final handoff, they'll likely set up their own facebook app on their account. This would significantly raise the stakes if someone decided they wanted to play with that access_token.
I'm mostly a front-end guy who's done some small php sites/apps, so what would you recommend I do?
Thanks for your time!
I don't know about facebook in particular, but typically if you want to protect api access credentials you would proxy the request through your server, and just send the results to the client (so the access key only exists on the server). Alternately, and I'm not sure that facebook provides this, some APIs will give you a user token, which does not expose your access key, but allows the client to call the api.
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.