shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Matthews <matth...@oclc.org>
Subject Re: Allowing an authorization server to provide an updated scope for OAuth2 tokens
Date Tue, 17 Jan 2012 17:54:56 GMT
Hi Matthew,

I think the usecase where gadgets can see the scope that was granted is
useful, but it¹s not what we had in mind.

Our use case is an application where a user authenticates and is associated
with an institution.  It¹s possible for a user to login with a different
institution context later. For example, the user may initially login and use
our UI in the context of Institution 1 and then later login and use the UI
in the context of Institution 2.  In this scenario, we want to avoid reuse
of an access token, issued by our authorization server, that was issued to
the user when they were in the context of Institution 1. To do this, we are
considering making our authorization server issue the access token with an
updated scope value.

I haven¹t figured this piece out yet, but we¹d have to provide a custom
implementation of one of Shindig¹s OAuth2 request handlers to modify the
scope when checking to see if an access token already exists in the
OAuth2Store. 

Mike  


On 1/14/12 10:45 PM, "Matthew G Marum" <mgmarum@us.ibm.com> wrote:

> Hi Mike,
> 
> I agree with your reading of the OAuth 2 spec.  The scope of the access
> token that is granted to the consumer does not have to be the same as what
> was requested.
> 
> I think gadgets need to be able to see the scope that was granted in order
> to cleanly handle situations were they have access to some but not all the
> requested resources.  Is this the use case that you had in mind?
> 
> Matthew G Marum
> Software Engineer | IBM Software Emerging Standards
> mgmarum@us.ibm.com | Office: 1 919 254 9702
> 
> 
> |------------>
> | From:      |
> |------------>
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
>   |Michael Matthews <matthewm@oclc.org>
> |
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
> |------------>
> | To:        |
> |------------>
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
>   |"dev@shindig.apache.org" <dev@shindig.apache.org>
> |
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
> |------------>
> | Date:      |
> |------------>
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
>   |01/13/2012 02:01 PM
> |
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
> |------------>
> | Subject:   |
> |------------>
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
>   |Allowing an authorization server to provide an updated scope for OAuth2
> tokens                                                               |
>>   
>> >----------------------------------------------------------------------------
>> -----------------------------------------------------------------|
> 
> 
> 
> 
> 
> Section 3.3 [1] of the OAuth2 spec suggests that an authorization server
> may
> issue an access token with a scope different than what was requested.  It
> goes on to say that the authorization server SHOULD include a "scope"
> response parameter to inform the client of the actual scope granted.
> 
> We'd like to take advantage of this in our internally developed
> authorization server. However it appears that Shindig does not look for
> this
> "scope" parameter in the access token response. It always uses the scope
> specified in the gadget (which is stored in the OAuth2Accessor).
> 
> It seems to me that the TokenAuthorizationResponseHandler should check the
> response from the token endpoint to see if it contains an updated scope
> instead of only using the scope from the OAuth2Accessor.  Does this seem
> like a reasonable interpretation of the OAuth2 spec? If so, I'd be happy to
> create a JIRA and contribute a patch.
> 
> Thanks
> Mike
> 
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-3.3
> 
> 
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message