I am developing a mobile application and am using React Native with a NodeJS / MongoDB API Backend.
I would like to add social authentication (Google/Facebook) to my application.
It is also important to me that the social authentication happens as a Native Login flow and not browser based (i.e. the user is not redirected to the browser to enter his/her credentials).
I also want to have some token returned whenever the user authenticates with either Google or Facebook so that I can use the token to call my API, verify that the token is correct and return user specific resources.
Most examples that I found use Firebase but I prefer not using Firebase since I am already using MongoDB. Other examples implement a WebView thus the user is redirected to the corresponding social provider via the browser and I also don't want that since I want to provide a Native experience.
I am also thinking to try and use one of the following libraries: https://github.com/FormidableLabs/react-native-app-auth or https://github.com/fullstackreact/react-native-oauth to implement this.
I am looking for any help/suggestions on how to implement this.
For Facebook, use react-native-fbsdk.
For Google, use react-native-google-signin.
Both do not redirect to browsers for login and have tokens should you need to use them.
Related
I want to implement a react-native app with social login (google, FB) only. I am not clear about the complete flow though.
I can use various react-native modules that are available for oauth based login from Google. I don't know what to do with the information I get back. For example, If I need to create a todo app, I would want to store the user email and task created on my local server. After obtaining the email from google, I can make an api call and store data into my server using email but that won't be secure enough.
How does this kind of flow usually work. Usually in web based social login, callback url will provide info to the server directly. How does it work without using WebView?
Any help is appreciated. Thanks in advance.
I'm in the process of building a Google Chrome extension, and have some questions about how to implement security into the application.
I need to access a couple of Google API's so am going to be using OAuth 2.0 for that. So basically from the extension I know which user is logged into the browser.
My extension then needs to get and post data to my (nodejs) API service. I want to ensure that the user requesting data is the same user that is logged into the browser. Is there any way of using the previous Google authentication process to also authenticate communications between the extension and my API? I dont really want the user to have to log in again, to access my API.
I'm sure I'm missing something simple, and I've not been able to find anything that fits this scenario
Follow the OpenID Connect auth flow and you will get an access_token and an id_token. The acess_token you will use to use to make authenticated requests to Google APIs as usual. The id_token will be used as authentication with requests to your server.
When the requests hit your server you will need to validate the token and you can then use the contents of the id_token to identify the user.
User wouldn't have to login on auth process provided if user is already logged in and you are using a web application flow (not chrome.identity APIs) but user would see the consent screen atleast the first time. However you can skip the account selector screen if you already know the email address by providing &login_hint= parameter.
I'm working on a project to connect Google Apps (Contacts, Gmail, etc.) to our own private software.
I'd like to use Hapi.js in order to achieve this, but since I have no expertise in the matter (OAuth, Google, etc) I found it to be quite challenging.
I wonder if it's posible to use Hapijs and Bell to handle the "ask permission" flow, and once authorized save the credentials to long-term uses.
Also, is it possible to use Bell to handle token refresh and consume api? (like requesting http://www.google.com/m8/feeds/contacts/default/full)
In the documentation for Bell, there's an example for twitter, basically you need to change the provider to Google: https://www.npmjs.com/package/bell
When you request access, you can add the parameter access_type with a value of offline. The server will response also with a refresh token that you can use in further requests to the API's without asking for the user credentials again.
You won't be able to store the actual user's credentials since it wouldn't be secure.
You can use the Google OAuth playground to learn more about the authentication process, here is the link https://developers.google.com/oauthplayground/
Here you can find more information and examples of using node.js and the Google API's
I built an AngularJS application calling some REST API's belonging to my own backend (using Play! 2.2).
I'm using Facebook OAuth client in order to authenticate my users.
As being a Javascript App, my Facebook App Token cannot be "hidden".
Thus, anybody who picked up the Facebook App Token, by just reading the Javascript code could grab a user access token in a "legally" way and therefore use my REST API's.
How could I prevent it?
What is the best practice?
One way would be, I think, to use the server side Facebook's OAuth mechanism, rather than the Facebook Javascript SDK.
In this case, the Facebook app secret would be stored on my server and unreachable from the outside.
But as being a Single Page Application on client-side, I really want to avoid page redirection and benefit of the "popup" feature that comes with Facebook Javascript SDK.
There are a couple of things you can do.
Using the server side ("code") OAuth flow for facebook auth is much more secure. You can still avoid redirects by opening your own popup to initiate the login sequence, similar to what the Facebook JS does (only it goes to your server first).
Enabling HTTPS on your application is usually a good practice...
And if you're worried about cross site forgeries you can implement something like an anti forgery state token. See http://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/ and also google's instructions here https://developers.google.com/accounts/docs/OAuth2Login#createxsrftoken .
How would I authenticate with Firebase in a chrome extension? I need to specify the allowed domain list in the Forge. Chrome domain for the extension is just a big hash-like string.
I did read this: authClient.login problems
But the hashed based domain of a chrome extension is not being accepted in the Firebase forge. Is there another way to go about it? Currently am just reading the cookie firebaseSessionKey to just assume that I am logged in. But surely that can't be as secure as letting Firebase validate this session key.
As Rob points out, authentication cannot work in an environment that does not enforce origin restrictions. The fundamental problem here is that any authentication provider (Facebook, Twitter, Persona, or your own service) cannot issue an identity to a browser - i.e. it is meaningless to use Facebook to login to your browser (or extension).
The F1 add-on for Firefox ran into a similar problem (http://f1.mozillamessaging.com/) - where you would authorize F1 to post on twitter/facebook on your behalf. The extension had a website to along with it, from where you would serve the login page and proceed as you would normally in a web page. You'll need some code to communicate between the web page and your extension, chrome provides the tools necessary.
I would recommend the same approach - create a web page on a real domain (Github pages is awesome for this) to go along with your extension. This means your extension can't work offline, but neither can your login or writing to Firebase!
This will work using Google Plus Login Flow which I believe is the only one that allows cross authentication so the scopes are Google Plus Login.
"www[dot]googleapis[dot]com/auth/plus.login"
So what is happening here is you will get the access_token from the extension which you will be sending to firebase with the request using authwihtoauthtoken specifying google as a provider along with the access_token acquired from chrome.identity.getAuthToken()!
https://www.firebase.com/docs/web/api/firebase/authwithoauthtoken.html
Now the fact is that this access token could be issued by any other app, so we need to make sure that it is valid and has been issued for our app, basically we need to know there isn't man in the middle trying to access our database.
This verification is being made by the firebase.
They will check if this token belongs to the same application as the token has been issued to.
So you will need to create another set of credentials under the same application in the google developers console as for your extension. We will be basically doing the same thing as if we were to do it for our webpage but we will be inserting this new set of credentials to firebase's google oAuth in their security section.
They will do this check for us there. They will verify with google if the token is issued to the same app.
That's it.
Background Information.
https://developers.google.com/identity/protocols/OAuth2UserAgent#validatetoken
Use case
Sending ID tokens with requests that need to be authenticated. For example, if you need to pass data to your server and you want to ensure that particular data came from a specific user.
When to verify the access
All tokens need to be verified on your server unless you know that they came directly from Google. Any token that you receive from your client apps must be verified.
Google has a tutorial how to do this for python found at:
"github[dot]com/googleplus/gplus-verifytoken-python"
So basically what is happening here is; instead you doing to verification from on your server, firebase does this verification for you when you enter the CLIENT_ID and APP_SECRET into the firebase and enable the Google Authentication.
The way to do this correctly is a combination or same style of verifying to whom the client_secret was issued. Chrome will give you a access_token and then this access_token will be checked on the firebase's backend.