Sharepoint 2013 and Oauth 2.0 - sharepoint

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!

Related

Instagram Client-Side (Implicit) Authentication not available?

I have searched google and I have seen a lot of related questions and answers on this issue but none of them are clear.
I am trying to use Instagram API and as far as I understand, since I am building a client-side app (VueJS) is not a good idea to store the client_secret on the client.
Based on the Instagram Documentation here it seems that there was a way to use implicit authentication.
The problem is that after Facebook took over Instagram and launched the Instagram Graph API it seems that there is no way to use implicit authentication.
Does anyone have any information regarding this? The only solution is to build a server-side app for authentication?
This can be solved using an access token.
This token can be generated and has to be refreshed at least every 60 days using a GET request and your app-secret.
This can either be done automatically, in that case with a server side application or by hand.
Source: facebook developer guide
If it helps I created a snippet for vue after wasting the better half of an afternoon on this matter.
You can find it here: https://gitlab.com/snippets/1957175

How to secure server API in order to reject fake-client calls?

I'm developing both server and client side of a web application and it is almost finish. Now, it is time to secure it.
I read lots of articles and Q-A sites to understand the principles of the concept. But there are still question marks on my mind.
There is a similar question here:
How do I secure REST API calls?
They suggested to use token-based security system, which is very common and practical way. Also services like Firebase, Auth0 are providing this security system.
And this is about "how and where to store token": https://auth0.com/docs/security/store-tokens
If so, how can token protect server from fake-calls while we are storing it in the browsers local storage?
Explaining it with an example in order to be clear:
My client-side code has a form with options. One of the option can be selected via drop down option and there are only "1,2,3,4" in those options. So that, client can never send a form with "5" value to the server. But what if someone use a API tool (for example postman) to send a form with a value of 5? Attacker still can add a token to that request. First login to system as normal user. Than open the developer console of the browser, copy your token and paste to the header of your fake-request.
Not allowing the cross origin calls may solve the problem. But I am not sure if this means server and client should run on the same domain (or host)?
Bonus from stackoverflow: Stackoverflow's use of localstorage for Authorization seems unsafe. Is this correct else how do we strengthen it?
They are also discussing the similar question from another aspect. (Not for the server security but for the user's security.)
Not related but in case of need: front-end is developed with Angular 5, server is developed with Java and Spring Framework.

JSON Web Token Auth Service - checking status on separate server to protect routes. NodeJS

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!

Making my web api secure?

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.

CouchApps and user authentication

I posted a variation of this question to the CouchDB user list and haven't received a response yet.
I'm curious to know if anyone else has built a so-called "CouchApp"; a pure HTML/JavaScript application hosted directly within CouchDB. If so, how did you handle user authentication? I'd like to be able to create a typical login form (username, password) and then use those credentials either against a view or some other mechanism before passing the user along to the application (while storing their (encrypted) user ID in a cookie, presumably).
I'm used to simply proxying through something like couchdb-python and a normal web server, but would like to know any best practices with respect to authenticating users in these kinds of CouchApps.
Edit: A year later, and this is now built into CouchDB. This video is a great demonstration. (Thanks Daniel!)
CouchDB has released a simple authentication api but has no in built authentication mechanisms as of yet. The simplest and easiest way to do this is to use an http proxy for authentication. However this has limitations on how much you can restrict access on a per document basis. When CouchDB gets some more support for built-in authentication modules then it should be easier.
If you want to try your hand at coding an authentication module then you can check out the source for the javascript security_validation tests in this file:
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch_tests.js
and the default_authentication_handler in this file here:
http://svn.apache.org/repos/asf/couchdb/trunk/src/couchdb/couch_httpd.erl
that would get you started anyway.
This question has been around for a while (1.5 years!) and things have matured quite a bit since it was answered. Watch the video above, but it doesn't explain how to build it into your app. It looks like most of the answers are now found here: Security Features Overview and at the end of this document: CouchDB Security.

Resources