I am creating a simple web api that returns json.
It will perform simple crud operations.
What is the best way to authenticate users, OAuth seems to be the main recommendation here but I'm looking for something I can implement myself simply, token based or and API key??
Any ideas suggestions tips would be great, thanks
UPDATE: Forgot to mention, this API wont be for general comsumption, its just for my own use but I want to make sure someone cant get in too easily if they stumble on it.
First of all in order to build a good API you should use other people's API to see how they work. To be RESTful an API key is used, which is just a really big random number or "cryptographic nonce". But really this is just like immortal session id to look up a users authentication information, which isn't that great. OAuth is great, if you want your own system kerberos is very secure.
It is possible to hijack json responses, which is a pitfall against json. If the API key is required for each request, then the attacker can't use this method.
Related
I´m bulding a website showing data from my API endpoint. The website should be usable without a login form, but the API may only be accessible by using the website. What´s the best way of ensuring this?
It does not need to be 100% perfect, but I´m honestly overwhelmed by the good (and bad) solutions for this. The website is server-side rendered and could hand over an API token, but there are also Json Webtokens and sessions.
Webtokens seem to be good, because they can be set to expire a minute after creation. But with them, I have to keep track of their usage to avoid multiple logins using the same token.
And making it worse: Is there a way to enable users to reconnect to a websocket-api without reopening the website (single-use api tokens would be invalid)
I would love to hear your suggestions and (if you know a good place) to learn more about this.
Kind regards,
Max
I have a Cloudflare Worker that presents a registration form, accepts input from the user that is posted back to the Worker which then sends that on to an Node HTTP API elsewhere (DigitalOcean if that matters) that inserts the data into a MongoDB (though it could be any database). I control the code in both the CF-Worker and the API.
I am looking for the best way to secure this. I am currently figuring to include a pre-shared secret key in the API call request headers and I have locked down what this particular API can do with database access control. Is there an additional way for me to confirm that only the CF Webworker can call the API?
If this is obvious to some I apologize. I have always been of the mind that unless you are REALY good at security it is best to consult those who are.
You can research OAuth2.0 standard. That is authorization standard for third party clients. Here is link: https://oauth.net/2/
This solution is the most professional.There are other less secure ways to do it, but easier to implement. Password and username, x-api-key, etc..
It sounds to me that you can also block all IPs and allow only requests from that specific domain name (CF Worker)
How would I go about deploying a web app intended for only a single user (myself)? I feel like making a login that only accepts 1 user is the wrong method and also easy to hack? Would it be a good idea to make it only accessible from a certain IP? Please advise! Thank you. Backend will be using nodejs.
If I were you, I would program the back-end the proper way. This involves generalizing the entire implementation so that any hypothetical user with the correct password could use your login system. You could still authorize and authenticate the application so that when anybody else tries to log in, you automatically decline their request. If you are concerned about security, ensure that you are using SSL, basic encryption, hash passwords and, most importantly, do not use your own authorization library. It is far more secure if you use OAuth instead of using an IP, for example. Last, but definitely not least, make it as hard as you can for hackers to steal your data in the client side. This way, you also learn a lot of things that might come in handy in the near future.
I need some clarification on how Sharepoint uses Oauth and what I can/can't do with bearer tokens.
What I would like to be able to do is to either retrieve a bearer token from Sharepoint, cross domain via javascript and/or set up Sharepoint to use the same machine key as my current Oauth server.
I've read most of this article and several others but it has me bouncing around without a clear example. :
https://msdn.microsoft.com/en-us/magazine/dn198245.aspx
Recap:
I need a code snippet for retrieving a bearer token from Sharepoint using Javascript, cross-domain and...
I need a walk through of sharing the same machine key for claims based bearer tokens with Oauth 2.0
And to clarify what I'm trying to do:
I will need to read/write to Sharepoint lists from different platforms and I want a standard way to do it. REST seems like the way to go. Our apps are being developed using RESTful services and Oauth. We've got all of that covered with html and javascript. I'd like to understand how to continue to use our current Oauth and REST patterns to create secure Sharepoint interfaces on our html apps as well as Java and C# using claims based bearer tokens. If I'm on the right track, please confirm and provide some clear examples/resources. If there's a better way to do this, I'm all ears.
Bearer tokens work similar to money, whoever has the token is the rightful owner. That is why the terminology "bearer" (who ever bears the token) comes in. The tokens mainly rely on only SSL/TLS for security. Whoever "bears" an access token will be allowed to come in.
To answer your first question, I did research and found what your are trying to do. If you want to write it in Java Script and use the cross-domain library, you won't need to provide the access token.
var executor = new SP.RequestExecutor(appweburl);
executor.executeAsync(
{
url:
appweburl +
"/_api/SP.AppContextSite(#target)/web/lists?#target='" +
hostweburl + "'",
method: "GET",
success: successHandler,
error: errorHandler
}
);
I got that answer from here: https://msdn.microsoft.com/en-us/library/jj164022.aspx
For your second question I think it is possible,but uncommon to do. Unfortunately I am not to fond with using the same machine key as your current Oauth server, sorry! If I ever come across that in the near by future I will be sure to answer that question.
To clarify what you are doing, yes it does look like you are on the right track. If your apps are all using RESTful services it looks like REST is the way to go for sure. REST is probably easier in the same sense, because it uses HTTP requests which are easier than doing say COBRA, RPC, or SOAP. If you are looking to be more secure more than anything, use something like SOAP. Though it is debatable.
Some good resources may be to look at the Microsoft Libraries. They have pretty good tutorials though some are not too clear. Microsoft has documentation about the difference between SOAP and RESTfound here:https://msdn.microsoft.com/en-us/magazine/dd942839.aspx This is the link to Microsoft's Library: https://msdn.microsoft.com/en-us/library/ms310241 OAuth,REST,and etc. can be rough and hard to understand. Documentation is out there, but for certain things like using the same machine key as your OAuth 2.0 is hard.
Sorry, if I wasn't too clear, but if you need more help just reply to this answer. I hope this helped you some-what and enjoy your day!
For a project I’m working on currently I am developing an API using Node/Express/Mongo and separately developing a website using the same tools. Ideally I want to host these on separate servers so they can be scaled as required.
For authentication I am using jsonwebtoken which I’ve set up and I’m generally pleased with how it’s working.
BUT…
On the website I want to be able to restrict (using Express) certain routes to authenticated users and I’m struggling a little with the best way to implement this. The token is currently being saved in LocalStorage.
I think I could pass the token through a get parameter to any routes I want to protect and then check this token on the website server (obviously this means including the jwt secret here too but I don’t see a huge problem with that).
So my questions are
Would this work?
Would it mean (no pun intended) I end up with ugly URLs
Would I just be better hosting both on the same server as I could then save the generated token on the server side?
Is there a better solution?
I should say I don’t want to use Angular - I’m aware this would solve some of my problems but it would create more for me!
First off, I'll answer your questions directly:
Will this work? Yes, it will work. But there are many downsides (see below for more discussion).
Not necessarily. I don't really consider ugly urls to include the querystring. But regardless, all authentication information (tokens, etc.) should be included in the HTTP Authorization HEADER itself -- and never in the URL (or querystring).
This doesn't matter so much in your case, because as long as your JWT-generating code has the same secret key that your web server does, you can verify the token's authenticity.
Yes! Read below.
So, now that we got those questions out of the way, let me explain why the approach you're taking isn't the best idea currently (you're not too far off from a good solution though!):
Firstly, storing any authentication tokens in Local Storage is a bad idea currently, because of XSS (Cross Site Scripting attacks). Local Storage doesn't offer any form of domain limitation, so your users can be tricked into giving their tokens up quite easily.
Here's a good article which explains more about why this is a bad idea in easy-to-understand form: http://michael-coates.blogspot.com/2010/07/html5-local-storage-and-xss.html
What you should be doing instead: storing your JWT in a client-side cookie that is signed and encrypted. In the Node world, there's an excellent mozilla session library which handles this for you automatically: https://github.com/mozilla/node-client-sessions
Next up, you never want to pass authentication tokens (JWTs) via querystrings. There are several reasons why:
Most web servers will log all URL requests (including querystrings), meaning that if anyone gets a hold of these logs they can authenticate as your users.
Users see this information in the querystring, and it looks ugly.
Instead, you should be using the HTTP Authorization header (it's a standard), to supply your credentials to the server. This has numerous benefits:
This information is not typically logged by web servers (no messy audit trail).
This information can be parsed by lots of standard libraries.
This information is not seen by end-users casually browsing a site, and doesn't affect your URL patterns.
Assuming you're using OAuth 2 bearer tokens, you might craft your HTTP Authorization header as follows (assuming you're representing it as a JSON blob):
{"Authorization": "Bearer myaccesstokenhere"}
Now, lastly, if you're looking for a good implementation of the above practices, I actually wrote and maintain one of the more popular auth libraries in Node: stormpath-express.
It handles all of the use cases above in a clean, well audited way, and also provides some convenient middlewares for handling authentication automatically.
Here's a link to the middleware implementations (you might find these concepts useful): https://github.com/stormpath/stormpath-express/blob/master/lib/authentication.js
The apiAuthenticationRequired middleware, itself, is pretty nice, as it will reject a user's request if they're not authenticating properly via API authentication (either HTTP Basic Auth or OAuth2 with Bearer tokens + JWTs).
Hopefully this helps!