thank you for your feedback.
Am 03.02.2011 02:01, schrieb Marius Scurtescu:
Following up on the Token Revocation extension proposed at:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
I am suggesting three changes to this extension:
1. Either drop client authentication or make it optional. If clients
want to revoke tokens, more power to them. If it is a malicious
client, why would the authorization server deny revoking tokens?
The impact of an unauthorized revocation is merely inconvenience since
the client has the go through the authorization process again.
Nevertheless, I would like to add some protection here.
My suggestion: the authorization server should require authentication
for clients having such credentials.
2. Can we drop the "token_type" parameter, as suggested before?
yes, we can. I will modify this in the next revision of the I-D.
3. "authorization server MUST also invalidate all access tokens issued
for that refresh token." can we change this MUST to a SHOULD?
Why? The server is only required to revoke the access tokens if it is
capable to do so.
In case of success, why is the server supposed to return 204 instead
of 200? Just worried that this will confuse clients.
because there is no response body (required). I'm open to change it to
200 but what data shall be contained in the response?
regards,
Torsten.
Thanks,
Marius
On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu<mscurte...@google.com> wrote:
On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
Am 12.01.2011 22:19, schrieb Richer, Justin P.:
Yes, let the server do the work. In practice, it's going to be looking up
the token based on the token value anyway (for bearer tokens, at least). All
the client really cares about is asking to "revoke this token that I am
sending you". If the client credentials and token are correct and
verifiable, then the revoke should go through.
What do others think?
I agree with Justin's suggestion, let the server figure the token
type. The server should be able to do that anyhow.
A client wanting to revoke both a request token and an access token will
have to make several calls to this, unless you want to put in a way to put
multiple token values in. I don't recommend that though, as it seems to me
an optimization for a problem nobody has yet.
the token_type does not control whether the server deletes all access tokens
associated with a refresh token.
This depends on the authorization servers policy.
There are cases when the server cannot revoke the access tokens
associated with a refresh token (static access tokens for example).
That being said, I think the server SHOULD revoke all access tokens if
possible.
Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
