I'm creating a REST API server with Node.js and Express + MongoDB.
This API will have different mobile clients (iOS, Android) and possibly a web app later on.
I need users to login in order to perform some API requests. There are no 3rd party apps I want to connect with (no Facebook, Google etc). I also don't want to force the users to visit a webpage or anything like that in order for them to login.
From what I've seen on my many searches on SO, the best approach would be to let users login with full credentials once, send them a token in return, and use that token to verify future requests until it expires.
However, I'm not sure how to implement this.
I'm very confused with all of the different strategies. Is this done with basic authentication over HTTPS, with OAuth, OAuth 2.0, ... ? I just don't know what to use.
Also, I really don't want to reinvent the wheel here, not because I'm lazy, but mainly because of security concerns. Is there a library I could use to implement this? I've heard of Passport, but I couldn't understand if this is doable or not. This sounds like such a generic thing I'm sure there's a simple solution out there.
Thanks!
Now you can use Passport.js with JWT (JSON Web Tokens) with Passport-JWT. It's pretty easy to use.
Once a user is logged in, you send a token to the user. The token contains data about the user, like an id (encoded, of course). On the subsequent requests (at least where authentication is required) you make sure, that the client sends the token. On the server, you can see who sent the request (and e.g. check the user's authorization), just by looking at the token. For more info on how JWT work check this out.
There are different ways to send the token. Just have a look at the docs and it'll be clear. If not, this also helped me.
I feel you need to setup a Token Based Authentication process in your server, so you can make requests from different types of clients (Android, iOS, Web, etc.). Unfortunately, Passport documentation (and Passport-based tutorials) seems to be aimed for "web applications" only, so I do not think you should be using it for those purposes.
I did something similar following this great tutorial: http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543
The client part in this tutorial is based on AngularJS, but can easily apply the same principles in a mobile client (it is just a matter of making HTTP requests including a token retrieved when you post in "/signin" or "/authenticate").
Good luck!
There is an example of RESTful service with oauth2 authentication: https://github.com/vedi/restifizer-example. I hope it will help.
Related
I've an API that uses OAuth authentication (hydra) to authenticated requests that are
coming from the user browser.
I would also like to send requests to the same API's also from another backend (NodeJS).
I'm a bit confused what is the best way to do it.
The current Authentication mechanism uses a refresh token (1h).
I was thinking about creating another client for the backend in hydra, but it seems strange that also the backend will use the same method with the refresh token like the browser (never saw this before).
Any help with how to address this issue will be appreciated.
So... there are several concepts you might need to take into consideration here...
Since its conception the OAuth 2.0 family of standards distinguishes between private (trusted) and public (potentially vulnerable to attacks) clients. The client you've got running in the browser falls in the latter category, and thus most experienced OAuth devs out there would argue that it's not OK to use refresh tokens for this client. For you backend service (even if it is a simple backend-for-frontend) written in node, that's a completely different story - there it's OK to use and store refresh tokens.
If however your node.js backend is working "outside" an active customer session, i.e. tries to access customer data even when no customer is actively interacting with the frontend, you might also want to consider the machine-to-machine flow provided by OAuth 2.0 - the Client Credentials Flow.
I'm kinda new to backend development and wanted to start by creating a small API with authentication and authorization that could function as an API for a blog for different frontend implementations.
I set up an API with ExpressJS and MongoDB and created a working API so I can post blog-posts, retreive all or single blog posts, etc.
Now I wanted to add Authentication and instead of using JWT or something, I thought, it could be cool to have my users sign in via their Google-Account to post/delete blog posts, etc. Does that even make sense? I hope it does because in my head it should not differ too much from using JWT for example.
I added passport.js and it's google-oauth2 strategy.
I'm already able to create users by signing in via google, but my problem lies in the way to authenticate correctly for login and subsequent API requests.
Would I use the access- and refresh-token that I receive back from google for that? At least thats what I first thought of.
But how would that work? And next up: What if I wanted to add another way to authenticate? For example JWT or maybe Facebook-OAuth? Wouldn't that cause some issues when trying to protect my API routes because I would have different ways of authenticating (and what kind of middleware would I use then for my routes?)
I hope I made my problem clear :)
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 need to register users with my AngularJS app. I would like hashing with salt to take place when storing the password into MongoDB. Then I would like the same user to authenticate and authorize for some of the actions he/she could take.
I come from Java/JavaEE background and have never done any registration/authentication/authorization work for a JavaScript app using MEAN stack.
Is there any reference/sample MEAN app I could refer to for understanding registration/authentication/authorization?
Should I be using Cookies or tokens for authentication?
Is there any reference/sample MEAN app I could refer to for
understanding registration/authentication/authorization?
I preffer passport.js. Plugs to express, Supports both Tokens and Cookies, it is easy to work with Angular.js via ajax.
Should I be using Cookies or tokens for authentication?
Take your own decision, but read this and this and this
I come from Java/JavaEE background and
Not clear but if you are new to web development, may be you should read this excellent post
I wanted to start a thread to understand practices people currently use to serialize user data in a Facebook (canvas) application running on .NET with the Facebook C# SDK.
Security: Has anyone exposed data endpoints that can be accessed in an AJAX-mechanism from a FB app? If so, how did you protect them? Seems like it would be simpler to access the data when doing a full postback in terms of security, but even there I'm not entirely sure about the security implications. I'm used to doing things with forms authentication so I'm pretty unsure of how to secure data in the FB context. Obviously not having passwords is nice but I still thought this was a worthwhile topic.
Thanks...
-Ben
If you are relying on Facebook authentication, the best thing you can do is make sure the signed_request is valid, the Facebook C# SDK does this for you. (By valid, I mean that it originally came from Facebook) However, you cannot ensure it came from the person that the cookie says is the user. The signed_request could be intercepted since it is frequently sent over non SSL connections. This question contains two answers that are worth reading and should answer your question. Facebook JS SDK: access_token in plain text and security
Regarding exposing the ajax endpoint. Just make sure you pass the signed_request to the endpoint and use the FacebookApp class to read the session. This will ensure that it is valid. Here is more information on that topic: Facebook C# SDK, AJAX in iFrame app