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
