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.
Related
Our application is currently written in .NET Framework + Razor, and traditional Membership authentication.
I am trying to modernize it, so I stawted to work on a .net core + react solution, but it has to cooperate with the existing application.
So currently, we have the old monolit, and an other .net core apis, called by react. The react is embedded inside the Razor.
Now I need to choose what authentication to use. I guess membership and other session based authentications can't be used, because there are multiple apps in multiple domains. So I need tokens.
I am not really sure about which solution can or should I use. I know buzzwords like bearer token, .NET Identity, OAuth + OpenId, but can I use any of them in this situation, to use it to protect the API and as well for the "traditional" razor app?
And where should I store the token? Should I store it in a session of the razor app, and pass it to the React too?
I need a solution where user credentials are stored in our own database, not something list Google's or Facebook's single sign on.
Is there a good tutorial for this?
You're asking for a lot here. I would suggest brushing up on this topic from the beginning. If you only know the buzz words you won't get anywhere quick. I can give some quick advice but if you aren't familiar with the basics this won't really help. There is no quick solution for your answer.
I would suggest authentication on the edge of the application to achieve a nice separation to work with the existing app. I would create a light weight method that receives the request from the client and gives the api gateway proof of the user identity in a way the API can verify. I would go with OAuth and OpenId Connect protocol to achieve this separation. Also, take a look at IdentityServer, it is an open source product that makes it easy to implement single sign-on and access control(Authentication) in web applications and HTTP APIs.
OpenId Connect to authenticate users
OAuth to limit collaboration for these light weight method calls
JSON Web Tokens (JWTs) for user identities
Now the problem with this solution is that there is a high level of trust between this light weight method call and the rest of the system. The principle of defense in depth would suggest to implement a layering strategy, so that if this layer is compromised another layer is there as the next line of defense. I'll leave the rest up to you.
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 going to create an API service for my clients to use. The api is gonna return some data that will be displayed to the customers using my client's website. The api does not need any kind of user data.
I was thinking to use an api key and use it to return the relevant data. But I want to make sure that only the customers using my clients website should be able to access the api.
My question is if I use the api in the front end and expose the api key anyone will be able to use the api from their browser. I don't want that to happen. How do I authenticate this? If that's not gonna work can I use the api from my server to client server? Even then how will I authenticate the server?
I'm using nodejs and express in the backend. Any ideas? Thanks!
This is a tricky thing to do; essentially restricting public apis. At the end of the day, the web page is going to be in the user's browser on their local machine. So if they can access it from their browser, then they can access them manually too. An API key is the best approach really, but this only acts as a deterrent more than access control. Pretty much any access control type you put into a browser can be mimicked outside the browser unfortunately.
If you want to go down the route of having users login to some extent you should look into json web tokens (jwt). This doesn't need to be on a user level, and can be on a sort of session level if you prefer. This however won't restrict the user accessing the apis directly.
If your API is public, without user authentication, then there is no way to restrict the access to it.
There are many workarounds like checking for referer or creating special tokens, but it will all be stored at client-side, and a malefactor can reuse it.
It all does not make sense in general. You have already exposed your API to your clients. Even if you create a working algorithm, a malefactor can simply run your website JavaScript methods to make it work. What are you trying to protect from?
If you to restrict the access to your API, then the most proper and efficient way is to make this API back-end, so that only your webclients at server-side have access to it.
I'm trying to call one of Magento REST APIs (say products api) from a NodeJS application using a regular HTTP Request. I know that Magento APIs requires OAuth to authenticate the user/application, and this is where I'm a bit lost.
With Magento or any OAuth application, the end-user who is using the app has to click "Authorize" in order for that application to receive the token, and then the application will be able to communicate directly with Mangento APIs.
In my case, we are talking about 2 servers, Magento and NodeJS, that will talk to each other. So There is no user involve to sort of "Click" the authorize button and validate the auth request.
The point of what I'm trying to achieve is grab product data from Magento, store it in a DB, then make some changes, after that make it accessible via NodeJS REST APIs. (That is a hard requirement and I can't change it).
My question is, Do we have to write custom Magento REST APIs that doesn't require OAuth, or maybe require the regular basic HTTP Authentication (username/password). Or there is a way to use OAuth and authenticate my Node application directly?
I hope my question is clear, if not please let me know and I will try to fix it. Thanks!
After wrestling with a similar situation, I decided to use Magento's SOAP API. All you have to do as far as authentication goes is to set up an API user in the Magento backend and then use the username/password in your API calls (I think, it's been awhile). Not sure if this fits your use case but it saved me a lot of OAuth headache.
I am making a small Rest based webservice. I have used OAuth and other authentication mechanism before but never implemented one by myself. Can some one give direction on how to do this in either NodeJs or even in any other framework.
Use this. It has a lot of examples inside that repo.
Besides of that OAuth I would use some api-key auth (maby generated in your online service). And of course limit the access - protect your servers from too large traffic from a single api-key.