Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
OAuth Extensions
Home
About this group
Join this group
Message from discussion Proposed Extension: OAuth Sessions for very large distributed sites
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Allen Tom  
View profile  
 More options Apr 14 2008, 12:42 am
From: Allen Tom <a...@yahoo-inc.com>
Date: Sun, 13 Apr 2008 21:42:26 -0700
Local: Mon, Apr 14 2008 12:42 am
Subject: Re: [oauth-extensions] Re: Proposed Extension: OAuth Sessions for very large distributed sites
Print | View thread | Show original | Report this message | Find messages by this author
Hi John,

I like your suggestion because  it eliminates the need to have a new
class of tokens and secrets. This would probably satisfy our
requirements as long as there was a way for consumers to refresh the
AccessToken/ATSecret without any user intervention.

When the SP returns HTTP 401 to the consumer, the consumer will need to
know whether or not it should refresh its Access Token (because the AT
is expired), or if it is required to go through the entire Auth flow
from the very beginning (because the AT was revoked).

If we go with this approach, then there's no need to define a new HTTP
Authorization scheme, because it's essentially the same thing as the
OAuth scheme defined in the spec.

thanks a lot,
Allen

John Panzer wrote:
> Hey Allen,

> So a dumb question... why can't the session scope be handled with a
> normal Access Token?

> 1. Get Access Token scoped to a short session via normal mechanism (say
> it expires in 30 minutes)
> 2. When AT expires, you get a 401 Unauthorized with a WWW-Authenticate
> and additional info indicating that it's just a session timeout
> (xoauth_session_timeout, say).
> 3. You then re-authenticate; I'd suggest that this be the same as a
> first-time authentication, but you pass in the expired Access Token
> instead of the Request Token.  This lets you do the DB lookup required
> to verify that the user's consent still stands, they haven't changd
> their password, etc. but also lets you mint a new 30-minute Access Token
> and return it to the client.
> 4. Lather, rinse, repeat.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google