Node.js security - mysql

I am building a basic app using node.js and mysql and just getting a hang of it, I would like to secure the api,like only allow certain people to access the data, maybe by passing a certain token each time a user requests for some information, I tried searching for certain tutorials which used node.js and mysql database and security, I am confused as to which security measure to use, I even read about Json Web Tokens but din't find a proper tutorial for that.Please point me in the right direction.
EDIT
What I meant to say was, only authenticated users are allowed to get access to data in the api, when a random visitor tries to access a URL he shouldnt be alowed to without proper authentication,what I am mostly looking for now is when a user is authenticated the user should be a sent a token of some sort so then gets access to private data,I don't exactly know how to go about this whole thing.Would be glad if you could clear it up for me.

I would look at implementing Oauth2 server in your app. I found this article useful:
http://blog.papersapp.com/oauth-server-in-node-js/

No sure what your exact question is about, but I think the below will help:
Node.js security tips: http://blog.risingstack.com/node-js-security-tips/
Secure Express apps with various HTTP headers: https://github.com/helmetjs/helmet
Go on an educational Web security adventure: https://github.com/toolness/security-adventure
Node.js Security presentation: http://www.slideshare.net/d0cent/nodejs-security?qid=c450507b-e491-4e9a-9b05-89d0c82ea10b&v=default&b=&from_search=6

Take a look at http://passportjs.org/ . Passport has support for alot of authentication methods, however, for your API, you will probably want to use OAuth (http://passportjs.org/docs/oauth2-api). OAuth is what most popular APIs use to authenticate consumers.
For simple projects, You can also use basic authentication, which is what you see when you see the browser prompt asking for username and password. This authentication information can be sent in the header when API consumers makes requests.

Related

authentication from mobile to backend django

Good day everyone. I am stumped at the moment and would appreciate some guidance. I feel like I am a great googler to usually find my answers or resources but for the life of me I can't seem to find any good learning material on JSON requests and responses.
So I took a course that builds a 3 part app. Web app with Django, and 2 mobile apps that make API calls to it. The instructor uses Facebook authentication from the mobile apps and I am trying to set up the apps for username and login and a registration page as well.
I have django models setup and and can make users from the web app but I can't seem to wrap my head around how to make JSON calls from app to Django. When I search for possible terms like authenticate django I get results that talk about only django usage.
Does anyone have some tips or links to resources that would help me understand the login process better. I realize that almost every app has a login which is why I'm surprised that I can't find any good learning material on how its done. Or I'm just searching for wrong keywords.
Any help would be great thanks.
It's really a general question, But i give you a brief on how mobile and django server should interact with each other:
First of all, in your situation I really suggest to use django rest framework, Because of it's rich modules and functionallity like serializers, routers and ...
read more about it from origin documentation here.
For authentication system, You should use a token based system (or session). I suggest use one of django suggested token based solutions for that. In my case i really suggest to use django-restframework-jwt library
(JSON Web Token Authentication support for Django REST Framework).
so whenever you want to send a request to mobile you should provide that token (based on token authentication backend you choose) in your headers of request.
And for login and register you should create APIViews that takes user input, then register or authenticated it with backend and then gives user the generated token for future requests.
And for social auth system like facebook, the main concept is to redirect user from app to facebook oauth links, which if the user authenticate in his facebook will redirect you redirect url of your backend server, then you should capture that request in callback, fetch data and create or get the user and generate the token for that user and return it. so that for furture requests, by sending token to server, server will know that which user is sending this request and handle response properly for that.
And if you want to create a login with mobile, then you need to setup APIs for login, register with django rest which is really easy and you can learn from it here.

Posible pitfalls when switching from Gmail smtp to Gmail rest api

Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.

Is it possible to build web Api application using dotnet core, MySQL with Authentication and Authorization?

I am trying to work out an application using
Dotnet Core 1.0
MySQL as the data store
Authetication and Authorization
Entity Framework
Ubuntu 16 machine
I have succeeded in creating a sample API to fetch data from MySQL database using entity framework. Now I want to introduce Authentication using email as username and Password.
I tried several method from different blogs but unable to achieve this.
What I am trying to achieve is Custom Authentication for the api where user will send username and password to login Api. The login Api will return an access token and refresh token. Using this access token, the user can call other APIs.
Later on I want to add Google and Facebook Authentication too.
Is there a way to do this?
Everything you want to achieve is possible. However there are some caveats.
Yes you can do this. You will need to use the resource owner grant which is turned off in identityserver 4 by default. I suspect the reason for this is because passing user credentials into an application is an anti-pattern, it is there to typically support legacy systems, also it does not authenticate users in the explicit sense because the credentials could come from an un-trusted source (as an example). You can read up about the grant's generic value here. You can find samples here.
The safer pattern is to use something like Implicit Flow which is good practice if you cannot guarantee trust between clients and your API.
As for social logins this is possible. There are tonnes of samples online but here are the official docs.
There is a project on github, https://github.com/diogodamiani/IdentityServer4.MongoDB and a corresponding nuget package that will send you in the right direction. It's obviously MongoDb, but the same premise applies.

How to get an OAuth access token from Google Cloud Messaging on a remote server

I have a general comprehension question about OAuth access token retrieval for a Google Chrome Extension.
I have a popup HTML window in the browser that uses Jquery to request data from the server (a LAMP stack on AWS). The data is presented by PHP scripts which access a MySQL database. All very basic stuff.
I now want to implement a push messaging system using Google Cloud Messaging to alert users of new content that they can check. However I don't really understand where I should request the access token and how to listen for the response. I figure it should be in the PHP scripts but all the Google documentation that I've read states the user has to be present in order to allow access to push messaging. That tells me I should put it in the JavaScript but I feel this is a bad idea because every user could potentially request an access token when I think I only need one every 3000 seconds or so. If my app was completely implemented in PHP I'm sure this would be possible and now I'm worried that splitting it up like this leaves push messaging out of the question. Am I missing a crucial detail or just out of luck?
If the data access you need isn't user-specific, then you're right, there's no good reason to get a separate token for each user. Check out https://developers.google.com/accounts/cookbook/roles/Apps which discusses some options.

How to learn to handle HTTP requests of protected resources?

I've wrote a tiny script that retrieves publicly available data from some APIs, in JSON format. I'm now trying to get some protected data out from bit.ly (click stats from a given user) and so I obviously need to authenticate via OAuth.
I don't seem to understand the role of client id and secret, as well as the user API key. I also don't get how to grab an access token (maybe generated during OAuth authentication?) to authenticate my HTTP requests of protected data. Do you guys know any good (e)book, article or any other resources I should read to understand in detail these architectural nuances of authenticated data retrievals and HTTP requests?
It is exactly as you suspect. The access token is granted during the OAuth process, which is basically a three step rocket of getting
Temporary credentials for your application
An end user needs to authenticate those temporary credentials, which grants you a verifier token
And finally you exchange your temporary credentials and the user verification for an access token.
Depending on which language/framework you are using, there are often good libaries available to help you implement an OAuth client. Check out: http://oauth.net/code/
But you will be well served by a clear understanding of how the whole thing works. Twitter has a great tutorial about OAuth 1: https://dev.twitter.com/docs/auth/oauth.
Regarding OAuth 2. Check out http://hueniverse.com/2010/05/introducing-oauth-2-0/. Hueniverse is a good resource for all things OAuth by the way.