views:

64

answers:

2

I'm trying to understand the use cases for which implementing oAuth as a service provider is the way to go. It seems that implementing an oAuth service is a lot of work, so I don't want to go through the trouble just to discover I was barking up the wrong tree. Any examples of such use cases to help me wrap my head around when to use or not use oAuth?

This question is related to another question I asked but they deserved to be separate questions. I provide detail on my specific use case here:

http://stackoverflow.com/questions/3932456/implementing-access-with-oauth-or-other

+4  A: 

OAuth is typically used when you want to provide a single point of authentication for multiple services, or if you want to integrate an application with an existing authentication service; e.g., if you wanted your users to log in with their Twitter account information.

In my experience, the only time I've had reason to implement an OAuth authentication service was because we had 3 very different applications running on different platforms (JBoss, LAMP, and ASP.NET) on different servers. To compensate for different databases and different technologies, we settled on an OAuth implementation and centralized authentication to one point. It also provided an excellent means of securing user information between servers; data is encrypted between OAuth Server and Client, making it harder to jeopardize.

It really depends on what you're trying to do. If you're just talking about one application, then OAuth is definitely too much too soon. If you're talking about a few applications that run on the same technologies, then you may or may not have to go with OAuth; you could just use the existing data store to authenticate with. If you're looking to scale out to multiple systems, or you're thinking of implementing a single sign-in type of service, then OAuth is definitely a consideration.

villecoder
+1 for a practical answer. My use case is actually this http://stackoverflow.com/questions/3932456/implementing-access-with-oauth-or-other I'd be thankful if you took a look at it and added any insights you may have for that one
samquo
+2  A: 

OAuth has a few things going for it:

1) OAuth is a fairly well known standard, which means there is quite a bit of information available about it, code libraries in a variety of languages and platforms, etc. This may be the most important aspect if you are trying to get widespread adoption of your site/service (ala Twitter, FB, etc)

2) OAuth has been reasonably validated from a security perspective so you don't have to worry (too much) whether it is conceptually sound. Your implementation of course is another matter...

3) As mentioned by others, OAuth is well suited for distributed/federated scenarios. This allows you to outsource the authentication responsibility (for example, Microsoft's Azure can do OAuth authentication on your behalf) and/or share credentials across multiple services.

Hope this helps!

Addys