He guys,
I have designed a 'Pragmatic RESTful' API. Not to Fieldings spec - but aligned to this http://www.restapitutorial.com/ - please leave the what is / isn't a RESTful API debate aside for now...
What I want to know is how to best secure my API. I see that Oauth1.0a is common, but I also see that it is deprecated. What is it that I should be using now? Oauth2.0? Or should I ignore the deprecation and go ahead with Oauth1.0a?
Also, if I am to use either Oauth 1.0 or 2.0, what flow should I be researching for an API?
Cheers,
Oauth 2.0 specification allows you to tailor the security to your needs. You will have to find out what works best for you and your situation if you were to use OAuth 2.0.
Although Hans says that Oauth 2.0 is safest, you must realize that many think most implementations of it are insecure (not because the specification is bad, but because it's so open and loose that people don't properly secure all areas like they should). Oauth 2.0 is more "loose" in the way it approaches the subject. If you look closely, the RFC spec for Oauth 2.0 calls it a "framework" while it calls Oauth 1.0a a "protocol". For that and some other reasons, companies like twitter have stuck with Oauth 1.0a. Although OAuth 2.0 is new, you will have to bring in other specifications, like JWT to secure it properly.
If I wanted to be sure that my API application was secure, I would definitely stick with Oauth 1.0a (tried and tested) unless you absolutely need some feature of Oauth 2.0 for now.
With Oauth1.0a there is really only one way to do things so your question as to "what flow" you should use is pretty much answered there.
OAuth 2.0 is the successor of OAuth 1.0a and many APIs have started to support it in favor of Auth 1.0a. Also, new developments - such as features that are comparable to the signed requests in OAuth 1.0a, called proof-of-possession tokens - are happening currently in OAuth 2.0 and no development is done on OAuth 1.0. So OAuth 2.0 is your safest bet for the future.
Related
Can someone explain how the backend of this protocols/standards works? I know they work on HTTP but I am not sure if they are REST or SOAP services.
This is confusing a bit.
Thanks!
OAuth and OIDC are REST APIs.
SAML precedes this and doesn't really have an API profile but I have seen SOAP being used.
i am developing an internal tool for bugtracking at my company. My question is: Will the support for the api-key based authorisation stop with asana connect?
We know the adventages about OAuth. But we are only a few people and we dont really need the OAuth - based stuff. We would like to use the old API authorisation.
Any chance?
Greetings from Germany,
Karsten
OAuth is a better choice for client applications, but for some cases (automated internal integration with SCM or bug management, etc., which it sounds like is the case you're talking about) the API key still makes sense.
If we ever deprecate the old API key, you can be sure we'll make it just as easy to get a one-off OAuth token for similar use cases.
OAuth allows the you the User to grant access to his private resources on one site to another site. But how exactly does this happen. And if I want to provide OAuth features in my site, (both as Service Provider and consumer), how do I go about doing it. I'm using a Fedora 13 based server. And is it possible to configure Round Cube / Squirrel Mail to provide these Services. Like as of now all my users have mail account in the server, I want the credentials in the mail to be used to provide the OAuth Services.
If you want to be a provider of data, then you have to implement OAuth server at your site and if you want to be consumer, you will have to implement OAuth client at your site.
You should also read some articles and tutorials to gain a better understanding of the protocol, because it's a protocol that allows to protect APIs and that being said, everything connected with security should be well understood by the developer that is imeplementing it.
In case that you're a provider, the 1.0 version of the protocol works in the following way:
Consumer requires access to end-user's private data
Provider issues a token to the consumer
End-user authorizes the token
Consumer can make authorized requests with that token for end-users's private data
Good place to start is: http://hueniverse.com/oauth/
You can also read the RFC when you decide if you will implement 1.0a or 2.0 version of the protocol. I have implemented only 1.0a so far, so I cannot give advice to which is better. I guess the 2.0 version has more possibilities, and everyone says it's easier to implement. As far for the easier, 1.0a is not difficult to implement also, because there are good open source libraries both for clients and servers and you can set up and run server or client for 1 day, if you understand the mechanics of the protocol.
Of course, if you want to make a good server with different scopes of access, inheritance of scopes and if your API is complicated and extensible, you will have to do a lot more work there, no matter if you choose 1.0a or 2.0 OAuth version
A simple example to demonstrate oauth flow. Understanding the concept helps to design accordingly:
As for the "How will I do it?"
There are lots of good libraries out there. Here is an excellent list: http://oauth.net/code/
I consider to use OAuth for Single Sign-On (SSO) with RESTful services. At first sight to use OAuth as the de facto standard looked naturally to me. But I must confess that I don't understand how to use it for SSO. During studying OAuth I discovered more and more criticism of Authorization - so much that I tend to think OAuth has failed.
OAuth is hard to implement.
Usability is poor.
Why Facebook doesn't implement OAuth today:
"OAuth is more complex and less performant than our own native authentication mechanism"
"OAuth WRAP looks like it will solve most or all of these problems"
Bad performance because of two many requests and long URIs
"Library quality is overall pretty poor"
Possibly WRAP, powered by Microsoft, Yahoo and Google, is going to replace OAuth.
What's going on with OAuth (and WRAP)?
So has OAuth failed? What are the alternatives for SSO - preferably those with wide acceptance or the perspective to become widely used? Would you prefer WRAP?
OAuth isn't a SSO solution, it's a protocol commonly used for delegated API authorization. 3 legged OAuth allows a client requesting access to a protected resource to delegate authorization to the server hosting that resource. Basically, the user doesn't have to give their credentials to a 3rd party (the client), only to the server hosting the protected resource. OpenID may be a more appropriate solution if you are looking to implement single sign-on. You can also use OpenID OAuth extension which will allow you to combine authentication with authorization via OAuth.
Work is currently being done on OAuth 2.0. WRAP was developed as a stop-gap solution to address some use cases not covered by the original OAuth 1.0a spec. WRAP will not replace OAuth, rather ideas from WRAP will make their way into OAuth 2.0 where appropriate. A number of the original authors of OAuth, as well as one of the authors of WRAP have written about this here:
What's going on with OAuth?
So no, OAuth hasn't failed, in fact it's enjoyed pretty wide adoption. OAuth 1.0 will continue to be implemented by a large number of providers and eventually OAuth 2.0 will be available as well. WRAP is there for people who want to take advantage of the use cases it addresses now.
With regard to the difficulty of implementing OAuth as a client, why not try it out? The available libraries are of varying quality, but with a decent one you can usually implement an OAuth client in under a day.
I have been investigating OAuth to share resources in my site to other sites.
But, hole of OAuth specification was reported several days ago.
http://oauth.net/advisories/2009-1
Many sites decided to stop OAuth until fixed version is released.
Currently, can we have any alternative to OAuth?
I want an open-standard and secure authorization protocol.
OAuth was built because there weren't any existing standards that solved the same problem. A fixed OAuth spec is forthcoming soon. It will be a pretty small change to the existing protocol.
In the short term, your best bet is to fall back on basic authentication mechanisms (requiring users to enter their credentials into your site for the foreign site).
Like Jonathan said, the hole will be fixed soon in the spec.
Oz is a web authorization protocol based on industry best practices. Oz combines the Hawk authentication protocol with the Iron encryption protocol to provide a simple to use and secure solution for granting and authenticating third-party access to an API on behalf of a user or an application.
OZ github link
Oz builds on the well-understood concepts behind the OAuth protocol. While the terminology has been updated to reflect the common terms used today when building applications with third-party access, the overall architecture is the same.
There was a revised version of the OAuth 1.0 spec, but since this question was asked OAuth version 2.0 is getting stable, and would often be the reccomended protocol.
OAuth version 2.O is a bit complex protocol compared to its predecessor, but more secure. It is specially tailored to address the security concerns of enterprises. Currently Facebook and Google authentication flows are based on OAuth 2.0
Oauth has come up with new OAuth 2.0 standard which is much more secure than OAuth 1.0 and 1.0a.It scaps access token and access secret and introduced access token and refresh token.Access token in Oauth 2.0 is validate for certain timeframe,after that it is regenrated or refreshed using refresh token.