Should an application be allowed to have more than one active access token per user OAuth 2?

48 views
Skip to first unread message

Ryan Zec

unread,
Feb 28, 2013, 6:10:23 PM2/28/13
to api-...@googlegroups.com
It doesn't seem to be anywhere in the spec so with OAuth 2, should an application be able to have more than 1 active access token for a particular user?  I am trying to think of a valid user case however I can't, it seems like if an application is trying to create multiple access tokens, it is probably trying to do something wrong (or bad).


Thanks,
Ryan Zec

Scotty Logan

unread,
Feb 28, 2013, 6:52:01 PM2/28/13
to api-...@googlegroups.com
On Thu, Feb 28, 2013 at 3:10 PM, Ryan Zec <bas...@gmail.com> wrote:
It doesn't seem to be anywhere in the spec so with OAuth 2, should an application be able to have more than 1 active access token for a particular user?  I am trying to think of a valid user case however I can't, it seems like if an application is trying to create multiple access tokens, it is probably trying to do something wrong (or bad).

Normally, every instance of a mobile app has the same client_id.  If the same app runs on multiple types of iOS or Android device, users with multiple devices will probably expect to be able to use the app on all of them.

  Scotty

Daniel Roop

unread,
Mar 1, 2013, 6:44:33 AM3/1/13
to api-...@googlegroups.com
We have a situation where we have two tokens.  So for context, we use OAuth for our Guest login (not just our delegated trust).  So when a guest logs into our website we generate an access token that is used from that point forward to access our API.  We also have server side and client side service calls.  IN order to reduce the risk of exposure, we provide the client side calls a different client id, so if for some reason a person were to be able to gain access to that token they wouldn't have fully access to the API.

Over time as we move more functionality to the browser the distinction may not be necessary, but that is a usecase we have found.


--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Daniel Roop

Travis Spencer

unread,
Mar 2, 2013, 3:25:12 AM3/2/13
to api-...@googlegroups.com
On Friday, March 1, 2013 12:10:23 AM UTC+1, Ryan Zec wrote:
should an application be able to have more than 1 active access token for a particular user?  I am trying to think of a valid user case however I can't

I can think of a few cases, all of which revolve around differing scopes or expiration times.
  1. A user has a short-lived AT for accessing higher-value assets and a long-lived AT for accessing low-level assets
  2. A user has an AT w/ some particular scope and then requests another with additional scopes
HTH! 

sune jakobsson

unread,
Mar 3, 2013, 7:19:18 AM3/3/13
to api-...@googlegroups.com
Given the nature of your API, you might have scenarios where you have
on access token pr resource. Your base URL could give access to all
kinds of resources.

Sune

On 2 March 2013 09:25, Travis Spencer

Travis Spencer

unread,
Mar 4, 2013, 3:34:47 AM3/4/13
to api-...@googlegroups.com
On Sunday, March 3, 2013 1:19:18 PM UTC+1, sune wrote:
Given the nature of your API, you might have scenarios where you have
on access token pr resource. Your base URL could give access to all
kinds of resources.

I can only see a need for one AT per resource under the following conditions:

1. Your resources are very broad (e.g., spreadsheets, calendar, etc.)

2. You want to control access to each of those independently (i.e., be able to revoke a client's access to calendar but not spreadsheets) 

So, very viable, but perhaps not the most prevalent use case.

If your resources are more fine grained, however, or you don't need to control access to each resource independently,   then scopes and one AT is the way to go.
Reply all
Reply to author
Forward
0 new messages