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.
Related
So these days I was reading about OpenID and OAuth2. I've seen some questions (this and this), but from what I've read you can use OAuth and for authentication, not just for authorization. On the second question, I've read this:
If you have an account (with some private resources) in a website, you
can log in with username/password couple. If an application would like
to get some private resources, and if you don't want to give them your
username/password, use OAuth.
But if you want to log in into multiple websites with a unique
account, use OpenID.
This raised more confusions (Dominick Baier said in one of his presentation that if you haven't heared about OAuth2 these years, you were living in a cave for the last years, so it seems this was my case): If I have many webservices (API's) and if I have an STS service to request tokens for all the API's then I am using OpenID? Is OAuth is not scalable to extend the authorization to multiple sites using a single STS service?
When you try to explain me, please consider that I haven't implemented an authentication or authorization process before.
You are right: lot of authorization servers based on OAuth2 provides a way to authenticate. But OAuth2 is not designed for that purpose.
In an OAuth2 context, the client has just an access token to retrieve/manage resources on a resource server. It knows nothing about the resource owner.
That is why the OpenID Connect protocol has been created. It works on top of the OAuth2 Framework protocol and allows the client to get information about the resource owner.
I recommend you to look at this very interesting talk (start at 4:44). This video helped me a lot to understand the purpose of each token. I hope it will help you too.
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/
What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?
They solve different problems.
SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.
OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.
They are two completely different things.
Some examples that might help out.
OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.
SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.
The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.
Alternatively, if you dont care about authorization, you could almost argue that asserting authentication via SAML and OpenID.
Have a look at this simple explanation summarized here:
Many people are confused about the differences between SAML, OpenID
and OAuth, but it’s actually very simple. Although there is some
overlap, here is a very simple way of distinguishing between the
three.
OpenID – single sign-on for consumers
SAML – single sign-on for enterprise users
OAuth – API authorization between applications
For folks comfortable with OO design patterns, I think there's a nice corollary to wrapper patterns. Think of Facade, Decorator and Proxy patterns. Fundamentally these are all the same, they're just wrappers... The difference is the intention of each pattern.
Similarly, SAML, OAuth and OpenID all facilitate different intentions via a common underlying mechanism, which is redirection to a service provider/identity authority for some private interaction, followed by redirection to the originating third party app.
Looking around on the net you will find overlap between the protocols' capabilities. Authentication via OAuth is perfectly reasonable. SSO over OAuth may not make a lot of sense though as SAML and OpenID are specifically geared towards federated identity.
To the question itself, in a corporate context SAML sounds more appropriate than OAuth for SSO. I'd bet if you look at the third party apps you'd like to integrate with your corporate identities, you'll find they're already designed to integrate with SAML/LDAP/Radius etc. IMO OAuth is more appropriate for Internet interaction between applications or perhaps applications comprising a Service Oriented Architecture in a large corporate environment.
Authorization rules may be specified in a corporate environment in other ways too. LDAP is a common tool for this. Organizing users into groups and associating application privileges against group membership is a widespread approach. Just so happens LDAP can be used for authentication too. Active Directory is a great example, though I prefer OpenLDAP.
Found Good article here
SAML (Security Assertion Markup Language) is set of standards to achieve Single Sign On (SSO), Federation and Identity Management.
Example : A user (principal) authenticates with a flight booking website, AirFlyer (identity provider) which has SSO configured via SAML with a shuttle booking website,Shuttler (service provider). Once authenticated to Flyer, the user can book shuttles on Shuttler without requiring authentication
OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication.
Example : A photo sharing mobile app (OAuth consumer) that allows users import photos from their Instagram account (OAuth provider) which sends a temporary access token or key to the photo sharing app that expires after some hours.
They handle a subtle use case
SAML - Sharing credential (e.g., SSO) of a user to various service providers (e.g., web or web service)
OAuth - A User delegating an App to access a resource on behalf of his/her
SAML has a variety of "profiles" to choose from allow other users to "log in" to your site. SAML-P or SAML Passive is very common and fairly simple to set up. WS-Trust is similar and it too allows for federation among websites.
OAuth is designed for authorization. You can read more here:
What's the difference between OpenID and OAuth?
SAML is for authentication - mainly used in Single Sign On scenario. OAuth is for authorization of resource representations.
JSON Web Token (JWT) is an alternative for SAML XML Tokens. JWT can be used with OAuth
A good reference is SAML vs. OAuth: Which One Should I Use?
The terms federation really means connection identities across systems. It's related to SSO but they aren't quite the same. I Found this blog post really helpful in terms of what federation really means.
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.