Thanks for the all the responses and help. The projects at work to combine openid and oauth are interested. However, I'm also bound by what the providers I choose to work with support.
What I've found is that Yahoo provides an optional parameter as Krishna described above. I've left a note on the Myspace developer forums about a work around I believe I've figured out there. I still need to examine what Google supports. On my end, I have sessions in place once the identity of the user is set. The primary reason I'm looking at oauth instead of openid is because I want access to extra profile information, and I'm trying to avoid having the user "log in" multiple times. I'm trying to preserve the user identity and the permissions they've granted not for a single session, but for all visits the user makes to the site over time. My project can be summed up like this. I'm working on a sports based social network. Working on Appengine, I'm working on more secure methods of handling user identity, as the current choice is Google's own built in system, or rolling my own. With limited ssl support I wanted to find a secure method for identity management that didn't require me to store password information for the users as I don't have a way of keeping them from being transmitted plain text to my site. OpenID, for identity management was a perfect fit. However, I also wanted the ability to supply users with easier ways to let their friends know about the site for viral marketing. Working with a small amount of storage (500MB), I don't have room for storing lots of user data. However, as a social network type site, profile pictures are important for things like comments for user identification. This is where I started looking at oauth. I could pull profile picture URLs, contact information to be displayed to the user, and even begin to look at things like pushing data back to the identity provider sites. The persistent profile on my site is important as I do want to keep some information locally. For example, a handle for the user to use on the site that's unique, as well as some site preference choices. Ideally, once I've managed the process of logging on from multiple providers on my target list, I'll also work on federating those logins. For example, my target list is Google, Yahoo, Myspace, and Facebook. 3 out of 4 of those support oauth, Facebook has it's own platform. If the user signs on with their Google account, I'll provide them the opportunity to add their other accounts also. The benefits being: - Access to friend data across multiple networks, giving the user the opportunity to "tell their friends" about content on my site easier. - If one identity provider is unable to process requests for some reason, the user can user another to log in and still have access to the same profile. >From the site perspective the benefits are: - I don't need to store any real user identity information. I don't have emails or anything to secure meaning if somehow my site is "hacked" the perpetrator has no valuable information to glean from my datastore. - By providing easier access to the profile information across several networks for a user, the options for viral marketing are stronger, hopefully translating to the site being more profitable. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
