Subject: [OAUTH-WG] Reusing access tokens with scopes that allow updates

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 17 Jun 2013 10:18:02 +0100

Hi, apologies if it is off-topic, though I'm hoping it won't be completely,

I'm working on a demo where an access token allows a client to update 
the end user's resource, example, a calendar. For example, the end user 
requests a reservation service to book some event and the user may allow 
the client to update a calendar at a specific hour only.

So in the authorization code flow, it may look like this:

- client requests a code with scopes like "readCalendar 
updateCalendar-7" where "updateCalendar-7" means a request to update the 
user's calendar at 7 o'clock.
- the user approves it and subsequently the client can update a calendar 
at the request hour only.

This has worked well in the earlier version of the demo, but now that 
I've started looking into extending the demo such that the end user is 
not requested an authorization every time this user asks the reservation 
service to book something by attempting to reuse the existing access 
token I'm seeing the problems.

The client (reservation service) associates an access token with a given 
user's alias and it seems that reusing this token before it has expired 
makes sense. However, the token was given to a client to allow update 
the calendar at 7'0 clock and now the end user requests to book 
something at 9 o'clock. So reusing that token seems wrong after all.

This led me to conclude that when an access token allows to update 
something then it is effectively a single-use token only, with its 
expires_in (and refresh_token) having no any real value.

Unless the end user is asked to 'widen' the requested scope, something 
along these lines: "The client has asked to update your calendar at 7. 
Do you want to allow it ? If yes - would you consider also allowing the 
client to update other calendar slots - this will let your authorization 
be reused until it has expired ?"

Something like that - which would mean an access token would actually 
get a scope like "updateCalendar-24" meaning the client can update any 
calendar slot while working with this given access token.

My questions are:
- Does it sound correct that unless the user allows otherwise, the 
access tokens with the scopes which allow for the modification are not 
reusable ?
- The idea of the end user widening the scope requested by the client, 
is it a wise idea at all ?
- What would be the preferred OAuth2 way to do it if widening the scopes 
is not recommended ?

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 17 Jun 2013 11:12:07 +0100

> - What would be the preferred OAuth2 way to do it if widening the scopes

I've thought a bit more about it and I guess it is not exactly the 
OAuth2 issue, but rather an application design issue. Specifically, it 
is up to a client to decide if it wants a token be reused (for calendar 
updates while the token is valid) or not and if it wants then it should 
request a wide-enough scope at the start of the flow, example, request 
"readCalendar updateCalendar-24" and let the user to either authorize 
the calendar updates at any time of the day or downscope the requested 
scopes to allow the client to read a calendar only and then for a client 
to report the end user it can not update the calendar.

I think I'm more or less clear on this but any comments will be of 
course welcome; again - sorry if it is off-topic

Sergey