In my current work, I have to develop an intern REST API engine.
I have read the Roy Fielding thesis, documented myself, and I finally got something that works great easy to use, with high performance, corresponding to the Fielding REST spec.
There is only one point that I dont really know how to overcome : the security problem.
Again, I documented myself, and I wanted to use OAuth2.0 in my engine.
The problem is that I dont understand nothing at all how to use this protocol.
I dont understand how the consumer can connect himself and be recognized by the server.
I dont understand if I have to provide API key to my consumer(like Facebook, Twitter and Google make it) or if a token will automatically be generated if I send a login / password to the server
I dont know if I have to create my own OAuth2.0 server that provides keys, or if OAuth2.0 libraries are sufficient to provide security.
In fact, I dont understand nothing at all with OAuth2.0, and I need to learn. The problem is, every documentation that I try to read is like chinese, I didn't find an easy one, step by step that will help me with this.
That's why I post here, can you help me understanding a bit more OAuth2.0 and the secured authentication for API ?
I willingly didn't speak about the technologies, because I want to understand OAuth2.0 before applying it technically.
Thanks for all
The main problem with OAuth (both versions) is that you'll see a lot of talk about the three legged version. That is when you have user, a data-providing service and a consuming service, let's say a service that will create physical copies of your flickr photos. In this case the OAuth flow allows the user to tell flickr that the third party can access their data. This is not the scenario you are after, you are interested in 2-legged OAuth, see here for a description.
Of course you could look at other methods too. I've used HAWK in a number of REST/Hypermedia APIs and found it to be great to use in both nodejs and .NET server stacks.
Thank you for your answer, I studied a bit more OAUth2 en tried to implement it with 3 stragery : basic, clientPassword, bearer.
I created a new thread for an other problem, if you want to take part of it :
OAuth2 server creation with nodejs
Related
My client is web based with a NodeJS server.
I've recently implemented Google Sign-In for server-side apps using this flow
see https://developers.google.com/identity/sign-in/web/server-side-flow
I'm now trying to implement something similar on Facebook but when I look at the docs there is no reference to oauth2.
https://developers.facebook.com/docs/facebook-login
Should I be using Facebook connect? Where do I get my "one time code" from so that I can send it to my server?
Lots of confusion on the subject. Some direction would be most welcome.
OAuth is, by design, not a very prescriptive standard. It describes various flows for doing the authorization, and each of those is specified broadly enough to afford multiple interpretations and implementations.
Facebook's implementation is broadly similar to Google's, and supports many different flows. The Javascript SDK offers a way of doing it in the browser, whereas the more traditional server-side flow uses a series of redirects and doesn't require any Javascript. Neither Facebook flow really calls itself OAuth, though the latter refers to it implicitly.
You asked about a "one-time code". That's a part of the Authorization Code flow described in section 4.1 of the OAuth2 specification. The server-side Facebook flow described above seems to be quite close to the specification, and the documentation describes how to get this code and exchange it for an access token. You could do it using the redirects, or you could write some Javascript to hit that endpoint in an XHR and then extract the code yourself and pass it to the server.
But you could also use the Javascript SDK to do essentially the same thing. It is based around the Implicit, browser-driven flow described in section 4.2 of the specification. In that case, the client is issued a short-lived access token. However, it can send that token to the server, and the server can then exchange it for a long-lived access token, similar to the use case of the one-time code. That process is described in the Javascript SDK documentation.
All of this is to say that I wouldn't worry too much about what is or isn't "OAuth". Most of these authorization services are based on the same basic OAuth concepts, but because the specification is quite general none of them work exactly the same way. Just figure out which flow works best for your application and use that.
I'm building an app that requires authentication and I'm worried users might want to be able to remotely log out. Is there a way to use JSON Web Tokens and be able to blacklist or reject them? I understand that their benefit is statelessness, but it would be nice to have a remote logout.
EDIT: With Express.js using the express-jwt module, there is a method to revoke tokens. Also, there is a module express-jwt-blacklist. I still don't understand how these strategies work and would like to know what is the best practice at this point.
There is a nice article on Auth0 about
Blacklisting JSON Web Token API Keys where they give a good real world example on how to blacklist a JWT API key so it is no longer valid. You should give it a read.
Framing the problem
Providing support for blacklisting JWTs poses the following questions:
How are JWTs individually identified?
Who should be able to revoke JWTs?
How are tokens revoked?
How do we avoid adding overhead?
This blog post aims to answer the previous questions by leveraging our
experience from implementing this feature in our API v2.
The article breaks down each point and then shows some example code on how to achieve it and concludes with:
Most of the aforementioned content applies to blacklisting JWTs in
general, not just JWT API keys.
Hopefully this blog post has provided some useful ideas on how to
tackle this problem.
I've personally applied similar methodologies to revoke multiple sign ins where the tokens were used similarly to session ids and stored in cookies. I modeled it like the GitHub profile section where you the user can see all your other active sessions and revoke them (remote sign out) when needed.
As far as best practice is concerned, I believe that topic would be rather opinion based. I do however see Auth0 as source of good practices in this topis area with a lot of people experienced on the matter.
UPDATE:
Found this express-jwt plugin for token blacklisting on npm
I'm new to OAuth and I would really appreciate if someone could give me a hand with my problem. I need to create a simple web application for track expenses, with some basic actions (user must be able to create an account and log in, list expenses, edit them, etc) with a REST API for each one, and the trick is that I need to be able to pass credentials to both the webpage and the API. So, after some research I've found some examples using Digest Authentication and HMAC Authentication but lot of posts also mentioned OAuth as an alternative approach, so my question is, given this scenario, would be proper to use OAuth? I mean, as far as I understand OAuth is suitable when you want to share resources with other application, which I'm not doing for this project; besides that, when you try to access the shared resource it appears a page requesting permission for the foreign application, would that page appear at some point in my application? (maybe after the login?)
Thanks in advance guys
In your current scenario it does not make sense to use OAuth. It's not what OAuth is designed for.
If your application ecosystem is going to have multiple webapps running on a single SSO (like google) then it is very helpful to have OAuth.
Suggestion: Decide based on your business/operation plan and implement accordingly.
Note: If you plan to have 10 apps in the span of the next 5 years but only have one app now it does not make sense to spend time to implement complex protocols like OAuth right now. Scale as you grow.
Jeff Atwood argues that we should stop asking users to register on our websites because we should rather use their "internet driver's license -- that is, [their] existing Twitter, Facebook, Google, or OpenID credentials" for authenticating them.
While I am beginning to think that he may be right, I could not yet decide and I am looking for arguments against letting foreign sites gain control over personal web pages.
Do you see any dangers of authenticating users like this?
if you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent .NET Rocks with Rob Connery which was precisely about this topic.
http://www.dotnetrocks.com/default.aspx?showNum=626
After listening to it I decided to NOT use OpenID on my site.
Here is the link to Rob's blog post on the subject:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Here are a number of reasons why not, although each comes with caveats:
If you only authenticate with one external service, anyone who doesn't use that service cannot use yours.
If your external authentication service goes down, users won't be able to use yours until theirs comes back up; similarly, slowdowns in their authentication server will also affect you.
Requiring users to authenticate with another service requires them to accept that service's EULA, which may be a turnoff for some; similarly, it ties you morally to whatever decisions your authenticating service makes. In particular it can make you appear to be a satellite, spinoff or affiliate of the auth site, since users have to see their logo every time they try to use your service.
The external auth domain gets a perfect snapshot of your viewership, giving them a lot of insight into what your company is doing. Since their analytical tools and staff are generally top-notch, they may conceivably know more about your user base than you do.
The major way to avoid this problem is to allow people to use the service of their choice, instead of a single service. If you are limited to developing one, for development time constraints, using OpenID is the best bet because many other authentication domains also qualify as OpenIDs, and therefore ameliorates most of the above problems.
I think using IDs from any of these big names are ok as long as you don't provide service that needs an endpoint like email, IM etc.
However, OpenID is just not trust-worthy. If you have any doubts, try this OpenID
http://opennoid.appspot.com/anyid
This is a disposable ID that doesn't require a password to login.
I'm working on a REST service that has a few requirements:
It has to be secure.
Users should not be able to forge requests.
My current proposed solution is to have a custom Authorization header that look like this (this is the same way that the amazon web services work):
Authorization: MYAPI username:signature
My question is how to form the signature. When the user logs into the service they are given a secret key which they should be able to use to sign requests. This will stop other users submitting requests on their behalf, but will not stop them forging requests.
The application that will be using this service is an iPhone application, so I was thinking we could have a public key embedded in the application which we can do an additional signature with, but does this mean we'll have to have two signatures, one for the user key and one for the app key?
Any advice would be greatly appreciated, I'd quite like to get this right the first time.
The answer is simple: It cannot be done. As soon as you ship any solution to the end user, he or she can allways attack the server it is communicating with. The most common version of this problem is cheating with hi-score lists in Flash games. You can make it harder by embedding some sort of encryption in the client and obfuscating the code... But all compiled and obfuscated code can allways be decompiled and unobfuscated. It is just a matter of how much time and money you are willing to spend and likewise for the potential attacker.
So your concern is not how to try to prevent the user from sending faulty data to your system. It is how to prevent the user from damaging your system. You have to design your interfaces so that all damage done by faulty data only affects the user sending it.
What's wrong with HTTP Digest Authentication?
I think the simplest way to do this right would be to use HTTPS client authentication. Apple's site has a thread on this very subject.
Edit: to handle authorization, I would create a separate resource (URI) on the server for each user, and only permit that (authenticated) user to manipulate this resource.
Edit (2014): Apple changed their forum software in the past six years; the thread is now at https://discussions.apple.com/thread/1643618
There is a better discussion of this here:
Best Practices for securing a REST API / web service