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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Mark Wubben
http://novemberborn.net
http://twitter.com/novemberborn
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
