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.
Related
The IANA registry of Authentication schemes (http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml) states that the Bearer authentication scheme is defined in the context of the Oauth protocol.
Does it make sense using a bearer token without an OAuth setting?
For example: I want to call an API of another company; we agree on a custom scheme for a JWT security token to add to an API call (for example, suppose you don't use an Authorization Server as OAUTH would require, we use another custom mechanism). The JWT is signed and encoded and added to an API call using the Authorization http header with a bearer authentication scheme.
The question is not if this can work, because I know it can and it is good enough from a security point of view (this is why I don't add much details about the real implementation).
My question is about use of the standards: from a formal point of view are we right if we declare a bearer token outside of an Oauth setting?
A second question could be: would it be possible to declare a custom authentication scheme, for example 'myBearer'?
Thank You,
Corrado Tamietti
I would recommend following a standard pattern for your B2B security. Usually this involves an Authorization Server, but if there isn't one, for reasons out of your control, then using tokens can still be useful, in order to:
Communicate scopes to represent areas of data
Communicate claims used for finer grained authorization rules
I would design a solution around the following rules:
Company B, who own the API, must issue the access tokens. Only they should have access to the private key used to issue them. They can then control privileges, time to live and other aspects.
Company A have to call a Company B endpoint to get an access token, which involves sending a credential. The token received should be fairly confidential and not contain sensitive data.
Company A then sends that access token to other Company B endpoints to access data.
Even if you keep OAuth behaviour light for the time being, this is a standard pattern that should fit nicely into your applications and support future extensibility.
USE OF AUTHORIZATION HEADER
The link you provided referenced OAuth 1.0, which used the OAUTH keyword
in the Authorization header - but very few people use OAuth v1 these days, partly because it is less web / mobile friendly than OAuth v2.
OAuth v2 best practice involves sending JWTs via the general HTTP mechanism of the Authorization header - see this section from the draft OAuth 2.1 spec.
If you are using standard JWTs (without more advanced features such as proof of possession) then using 'bearer' feels like the right option to me. This describes only how the API message credential is presented and does not have to mean that a full OAuth solution is in place.
FURTHER DETAILS ON AUTHORIZATION AND B2B
OAuth B2B APIs usually use the Client Credentials Grant, and if data sensitivity is high, step 2 often involves use of Mutual TLS. Here are some related links from the Curity Web Site:
Scopes in APIs
Claims in APIs
Financial Grade B2B APIs
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.
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.
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.