Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,

thanks for your feedback.

After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
implementations. OAuth leaves so much freedom to implementors (for good
reasons), which we should preserve.

What does this mean? I would like to focus on the revocation of the
token actually passed to the revocation endpoint and leave the impact on
other related tokens and the authorization itself to the authorization
server's policy. The authorization server may incorporate the client
type into its revocation policy.

My base assumption is that a client must be prepared to handle
invalidation of tokens at any time. So from an interoperability
perspective, it's not necessary to dictate a certain revocation policy
to authorization servers.

Current text:

In the next step, the authorization server invalidates the token and the
respective authorization. If the particular token is a refresh token and
the authorization server supports the revocation of access tokens, then
the authorization server SHOULD also invalidate all access tokens based
on the same authorization (seeImplementation Note <#impl>).

The client MUST NOT use the token again after revocation.

Proposal:

In the next step, the authorization server invalidates the token. The
client MUST NOT use this token again after revocation.

Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization.
If the particular token is a refresh token and the authorization server
supports the revocation of access tokens, then the authorization server
SHOULD also invalidate all access tokens based on the same authorization
(seeImplementation Note <#impl>).


This implies that some ASs may, in theory at least, allow the client to revoke the token but keep that specific client's authorization...

Cheers, Sergey

Thoughts?

regards,
Torsten.

Am 26.12.2012 15:38, schrieb John Bradley:
We don't want to share grant information across multiple instances of public 
client.

However we don't necessarily want to preclude multiple instances of a private 
client,  Though how the AS would tell them apart is a interesting side question.

 From a revocation point of view if you revoke the grant for one instance of a 
client you revoke it for all, though for a public client the grant is not doing 
anything anyway as the AS shield not be pre approving based on the grant.

There are still some open questions about an extension to identify client 
instances, though personally I prefer to have each instance with it's own 
client ID.

The language around grants has always been a bit philosophical for my taste.

If I recall correctly in the code flow the code is the representation of the 
grant.  In  the implicit flow the grant is implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to represent 
this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten Lodderstedt<tors...@lodderstedt.net>  wrote:

Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:
The draft relies heavily on the definition "access grant", but no definition is provided 
in the draft or RFC 6749. It's been my interpretation that an "access grant" is the 
*fact* that a resource owner has authorized a client (potentially scoped) access to the protected 
resources. Once access is granted in this manner, further access tokens may be obtained without 
explicit permission by the end-user. That is, in the Protocol Flow there is no user input between 
steps A and B.
That's correct.

In "1. Introduction" it is stated:

  A
    revocation request will invalidate the actual token and, if
    applicable, other tokens based on the same access grant and the
    access grant itself.
then, in "2. Token Revocation":

  In the next step, the authorization server invalidates the token and
    the respective access grant.  If the particular token is a refresh
    token and the authorization server supports the revocation of access
    tokens, then the authorization server SHOULD also invalidate all
    access tokens based on the same access grant
This implies that an access grant only applies to an app authorized on a single 
device. If an app is installed on multiple devices and the access grant is 
shared between both instances, revoking device A's access token results in the 
unexpected revocation of device B's token.
You raised an interesting point. Is it desirable to share an access grant among 
different client instances? I would like to discuss this topic in the working 
group.

If we assume it is desirable, how would the authorization process look alike?

I would assume that as result of the authorization process of the 1st client 
instance, the authorization server stores an access grant, which is identified 
by the client_id and the user_id of the resource owner. Moreover, it creates a 
refresh token, which the 1st client instance uses to obtain new access tokens. 
As this client is public, the refresh token is the credential the intial client 
uses to prove its identity.

How does the 2nd client instance join the party? I would assume the 2nd client 
to initiate another code grant type flow (using the same client_id as the 1st 
client). I see two ways the authorization server could process this process:

1) After authenticating the resource owner, the authorization server finds the 
existing access grant for the client_id/user_id combination and automatically 
issues tokens w/o further user consent. Since the authorization server cannot 
authenticate the client_id, a malicious client could obtain and abuse the 
access grant of the legitimate client. That's why the security considerations 
of the core spec 
(http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:

The authorization server SHOULD NOT process repeated authorization
   requests automatically (without active resource owner interaction)
   without authenticating the client or relying on other measures to
   ensure the repeated request comes from the original client and not an
   impersonator.

Validating the redirect URI won't help that much, since this URI is typically 
device local (custom scheme or localhost).

2) The authorization server asks the resource owner for user consent and issues 
another pair of access/refresh token to the 2nd client. In this case, why would 
one bind this tokens to the already existing access grant? This would limit the 
resource owners capability to revoke grants for particular instances. I would 
rather create another access grant.

Based on this thoughts I think it is not desirable to share an access grant 
among different client instances.

What do others think?

If "access grant" could be defined as "an authorization issued to the  client, based 
on the single use of an Authorization Grant" it becomes clear than only the tokens spawning 
from the app's authorization on device A should be revoked.
I would like to adopt your proposal if the WG agrees.

---

I spotted a typo in "3. Implementation Note":
Thanks. Fixed.

regards,
Torsten.
Whether this is an viable option or
    whether access token revocation is required should be decided based
    on the service provider's risk analysis.
"an viable option" should be "a viable option".

On 24 Nov 2012, at 18:13, Hannes Tschofenig<hannes.tschofe...@gmx.net>  wrote:

Hi all,

this is a working group last call for draft-ietf-oauth-revocation-03 on "Token 
Revocation".  The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-03

Please send you comments to the OAuth mailing list by December 10, 2012.

Thanks,
Hannes&  Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to