[oauth] Re: Service Providers' support of the Authorization header
On 2/19/09 1:37 PM, "kellan" wrote: > On Thu, Feb 19, 2009 at 2:23 PM, Eran Hammer-Lahav > wrote: >> >> Are there any providers our there without support for the Authorization >> header (as a way to send OAuth parameters)? > > I could launch one if that would help. That's nice. >> Any reason why Service Providers should not be required to support it? > > Didn't we spend quite a bit of time discussing this? We didn't. We discussed other requirements but the auth header was always an afterthought when the spec was written. It was a nice-to-have. >> Are there any providers who do not return the WWW-Authenticate response >> header with 401 replies? > > Flickr API doesn't. We support several auth protocols, not all of > which have defined behaviors for 401/WWW-Authenticate. Is there a reason why? EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Service Providers' support of the Authorization header
On Thu, Feb 19, 2009 at 2:23 PM, Eran Hammer-Lahav wrote: > > Are there any providers our there without support for the Authorization > header (as a way to send OAuth parameters)? > I could launch one if that would help. > Any reason why Service Providers should not be required to support it? Didn't we spend quite a bit of time discussing this? > Are there any providers who do not return the WWW-Authenticate response > header with 401 replies? Flickr API doesn't. We support several auth protocols, not all of which have defined behaviors for 401/WWW-Authenticate. -kellan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Service Providers' support of the Authorization header
Are there any providers our there without support for the Authorization header (as a way to send OAuth parameters)? Are there any libraries without support for the header? Any reason why Service Providers should not be required to support it? Are there any providers who do not return the WWW-Authenticate response header with 401 replies? EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Best practices for re-authenticating
On Thu, Feb 19, 2009 at 06:21:22PM +, Blaine Cook said: > I'm not sure that I understand the terminology correctly (what's the > difference between the API key and the token/secret pair?) Sorry, I'm confusing terminology. By API key I meant consumer key/secret. Too much time spent bouncing between GData, FlickrAuth and OAuth unfortunately. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Best practices for re-authenticating
On Thu, Feb 19, 2009 at 5:48 PM, Simon Wistow wrote: > > An user has walked an app through to getting the access token/secret and > has been using the app successfully then somehow loses them. > > What's the recommended practice here? > > - nuke the old pair and reauthenticate to issue a new pair? > - reauthenticate and hand out the old pair? > - keep the old pair but issue a new pair? > - force them to get a new API key? I'm not sure that I understand the terminology correctly (what's the difference between the API key and the token/secret pair?) In any event, the "correct" behaviour in the event of an app losing an access token/secret is that that app should act as though it had never authenticated the user before. The service provider doesn't need to do anything special, and neither does the consumer app. As far as cleaning up unused tokens, that's probably the responsibility of the service provider, based on their policies. For example, it could be something like "tokens that haven't been used for successful authentication in six months will be deleted." The worst case is that an application would need to be re-authorized if the token were deleted. > As a related problem - what's the best practice in that case? Should > each instance of the app have a separate access token/secret or should > they share? Each instance should have a separate access token / secret. There may be situations where sharing makes sense, but I can't think of any. ;-) b. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Best practices for re-authenticating
An user has walked an app through to getting the access token/secret and has been using the app successfully then somehow loses them. What's the recommended practice here? - nuke the old pair and reauthenticate to issue a new pair? - reauthenticate and hand out the old pair? - keep the old pair but issue a new pair? - force them to get a new API key? All have advantages and disadvantages not leats when an app embeds it's API key and then the user uses it on multiple machines. As a related problem - what's the best practice in that case? Should each instance of the app have a separate access token/secret or should they share? /Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OpenID Guides
I think the #1 thing to keep in mind regarding OAuth is that it's not
the sum total of what folks will be doing.
We all tend to be a little steeped in things here, but in many respects
the OAuth specs are a bit like telling folks interested in building
houses how to forge the steel for making their hammers. Regardless of
how simple or complicated OAuth happens to be, it's just one tiny part
of a much larger solution.
People also have a really hard time thinking in abstract. Where Facebook
wins is that they present effectively a single solution to the problem
of "Who is this person?" For site owners, they don't have to worry about
user management since all that is now someone else's problem. The recent
OpenID+OAuth+PortableContacts solution is a good first step, but it
still doesn't make the lives of site operators all that much easier.
Sure, accepting IDs from sites like Yahoo and Google are easy, but what
about delphicresearch.com, unitedheroes.net, or gnomebondage.com? (Ooh,
EvilOnAStick.com was available? Look out Billy Mayes!)
The best way to get this stuff out there and used is to make it damn
easy. It's why I keep pushing for a set of common libraries that folks
can hook into. Is it easier to worry about SBS double escape issues and
XRDS specifications, or call something like
user = OpenConnect(userId).userInfo;
if (user.isValid) {
print "Hello " + user.fullName();
}
The sooner we can get beyond defining the OSHA standards for carbon
content of hammers, the sooner we can start building really useful stuff.
Chris Messina wrote:
> I just discovered this site and thought that it was something that we
> really should continue doing for OpenID (and OAuth):
>
> http://guides.rubyonrails.org/
>
> After reading Joseph's blog post yesterday:
>
> http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/
>
> It's clear that we must make these technologies easier to implement,
> and we can start by making more tools and recipes available.
>
> As you're doing your own implementation, please share feedback and
> your own approaches and take notes along the way where things didn't
> make sense or where the specs weren't clear. It would be great to get
> this feedback in one place, and then write documentation to help
> others avoid similar pitfalls.
>
> Feel free to use the respective wikis to documents these issues.
>
> Thanks!
>
> Chris
>
> --
> Chris Messina
> Citizen-Participant &
> Open Web Advocate-at-Large
>
> factoryjoe.com # diso-project.org
>
> citizenagency.com # vidoop.com
>
> This email is: [ ] bloggable[X] ask first [ ] private
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: OAuth Community in Orkut
Link : http://www.orkut.co.in/Main#Community.aspx?cmm=60628517 On Feb 19, 5:02 pm, Tech Wizard wrote: > Hi Friends .. > > Take part in the OAuth community in orkut and lets make it active > > Regards ... > > Karthik --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] OAuth Community in Orkut
Hi Friends .. Take part in the OAuth community in orkut and lets make it active Regards ... Karthik --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
