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
