(Tom Vaga asked a similar question here but Luke's response didn't quite address what I'd hoped to accomplish... I'd comment there but don't have the points yet :-) Thanks! )
I've got a Slim server working well to register and authenticate users for our API, using JWT, allowing only 'authenticated' users to access certain api endpoints.
I'm now trying to setup a SocketCluster for various realtime messaging parts of the app, and I would like to restrict subscriptions to only authenticated users. I may be missing a part of the concept, but is it not possible to use the token-cookie set successfully by Slim to also authenticate to SocketCluster? (ideally using the built-in authentication process, and without having to call-back to the slim-api?) They're on different servers as sub-domains... Would I have to insert the same secret into the SocketCluster configuration somewhere?
Thank you!
Related
My architecture consists of a front end server and a backend/API server. The API is accessible to the end user, however I want the front end server to be able to access certain routes of the API that aren't accessible to the end user (higher privilege).
This question has 2 parts:
(1) I need to use API keys for the end user. What's the best practice to do this?
(2) How does the front end play into the API Key system? The client will need to log into their account to access these elevated privileges available from the front end. (such as enabling webhooks)
My application is hosted on Google Cloud App Engine Standard env and I'm using node.js 10. It would be awesome if anyone had any suggestions relating to this architecture.
I know this question is somewhat general but I've spent a few hours looking around online and my question isn't so much how to use API keys, nor how to authenticate frontend, but rather: what is the best practice to do these two together?
Thanks,
Nikita
JWT (https://jwt.io/introduction/) can help with this. You can include API key as well as JWT in the request header. Some services accept API key as a URL parameter but putting such sensitive data in header is a better approach.
JWT can be stored in the cookie when the user authenticates and can be transferred with the request to the server.
The server can use API key for authenticating and decode this JWT using the key available in the server environment for authorizing access as decoding this JWT can reveal the type of user and hence aid is figuring out what level of access is required.
A straight-forward approach used with multiple variations. You can start with the basic version and keep adding layers/features progressively.
I developed my Heroku app that exposes APIs only (no UI) and it works fine.
But how can I restrict the APIs to certain authorized/authenticated users only?
I absolutely need an authentication layer to protect the app APIs and prevent unauthorized accesses. A sort of login(user, psw) call to use before an external system can start invoking my API.
But I don't find any reference in the docs, it only says that these are the main security best practices:
Heroku SSL
Force the use of HTTPS
Trusted IP Range
Any idea?
That's something you'll need to implement at the application layer and not something that Heroku provides. At it's simplest you could implement basic auth in your app so that the user would pass them with their request, a more complex solution would involve user accounts and oauth etc etc.
You could implement all the authentication logic directly in your app.
Alternatively, take a look Auth0, which basically provides you with authentication and identity management as a service. You can easily add Auth0 to your Heroku app as a free add-on via the Heroku Elements marketplace.
They have lots of different use-cases and associated walk-throughs, and they offer a very generous free-tier.
From your requirements, it sounds like you might want to look at Auth0 Machine to Machine applications, using the OAuth2 Client Credentials Grant. With that, your external system(s) would basically need to authenticate with Auth0 using a Client Id and Client Secret (that you could generate in Auth0 and supply to them). Then, they would access your API with a JWT that you could easily validate in your app (Auth0 will provide you with generated code in many different languages for you to do that very easily). Your API will then reject requests without a valid JWT (by sending a "401 Unauthorized" response).
This may all sound a little intimidating at first, but it's really worth going through the relevant Auth0 "quickstart". They really go out of their way to try to make it as easy as possible!
I have in the past done a hand rolled app that stores a user token on client side $window.sessionStorage.
I have since then realized this is not safe. I am now looking for the most safe, standard way to secure an app that uses a node/express backend api that I will make, and also uses a front end that makes requests to this api such as angular for web or a native mobile app. Plus, whenever I would close the browser, I would have to re-log in because the $window's session storage was wiped out.
From what I've researched thus far, one of the safest ways to date if you're going to handroll it is to store a jwt in an http only secure cookie.
However, I'd kind of like to use a service that already exists, such as oAuth. Couple questions:
1) How safe is oAuth in terms of keeping ownershp of your userbase? What if 3 years from now oAuth just suddenly or slowly dies out? Aren't all my users technically stored on their server? How would I keep my users native to my app?
2) If I'm going to be creating a startup app in the same realm as snapchat, twitter, tumblr, etc... would it be generally recommended to use a service like oAuth to handle my authentication? Of course the future is unknown, but assuming the best, that my app would reach millions of users, would using a service like oAuth still be a smart choice? It seems like once you start using oAuth, there's never any going back to storing your users in your own database a year or two down the road.
Thanks
OAuth is an open standard for authorization.
Maybe you're thinking about Auth0. There are a lot of services that can handle user authorization for you, including Auth0, Stormpath, Apigee, UserApp, AuthRocket or Amazon Cognito. Whichever you choose, make sure that you can get the database from them in case you want to stop using their service. Not everyone explicitly offers an easy way to leave them but if that's important for you then make sure who suits your needs and who doesn't, and base your decision on that.
As for OAuth, see the https://en.wikipedia.org/wiki/OAuth article.
There's a huge list of OAuth providers on Wikipedia but those are services like Twitter, Google or Facebook. In a way you can use one of those services to manage all your logins but as soon as they see you as their competition, you're in trouble. I've heard stories like that.
Some interesting read on the subject:
The dangers of OAuth/Social Login
Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services
OpenID Vulnerability report: Data confusion
Social Login Setups – The Good, the Bad and the Ugly
I'm attempting to create a simple Hybrid Application with native API using Cordova.
I think to use a simple REST API remote to retrieve user information.
First time users have to register into server to gain account, and then the app could manage all user's api via AJAX calls.
Now, I'll appreciate your opinions and suggestions about:
I thought use LARAVELL to manage routing and authentication: there's some contraindication to this approach?
(and principal question): I've no advanced notions about security... so someone can suggest how to manage security data and remote login?
For example: store user password and username to localStorage, and send username + token to remote DB.
My problem is how implement security when make remote REST call, that is how pass data for remote connection.
I hope my questions are understandable...
Thanks
Found complete tutorial to my answer, via JWT and access tokens.
The link is:
https://scotch.io/tutorials/token-based-authentication-for-angularjs-and-laravel-apps
Very very powerful!
Hope help someone,
I am a complete beginner, and have just started learning about web development. Now I am asking myself some questions regards REST API: Does it make sense to secure a REST API with authentication? If so, what are the common ways of doing this?
I am under the impression that REST API's are precisely there because we try to enable many different users to access them. Now I would like to write a small application which makes requests to a node.js server and gets some stuff back. All via REST API.
However, I do not want others to be able to make similar requests to that server though. How would I best secure this? Am I misunderstanding something big time here?
Not authenticating the REST APIs means you are allowing everybody to hit your REST endpoints. It is a better practise to authenticate REST APIs and allow only certain users to access the APIs. The link might help you to have a start.
It is super simple: when you provide a service, most likely, you only want to allow certain, authenticated users to call that service. In other words: it is possible to have rest services that work without any kind of authentication - but is rather the exception, not the rule.
The more common approach is that, say a hotel only allows people with a key to enter rooms. Same story for services ...
And there are many ways to do that, see here for a starting point.
Authentication is important for REST APIs because you only want certain users to access your data via GET api and/or be able to make modifications to your database via POST api.
JSON Web Tokens(JWT) is the most commonly used authentication framework. Here's a very basic tutorial about how to authenticate node js API with JWT.