+1 on the support.
Torsten, I just wonder if you see this as (possible a part of ) a
single-sign off method?
Igor
Torsten Lodderstedt wrote:
Hi Eran,
in my perception, there is some support on the list for having a
request to revoke refresh tokens. Will you add such a request to the
specification? Do you need a text proposal?
regards,
Torsten.
IMHO this would look more like a hack than proper protocol design. We
need
a delete/revoke operation that's the pendant to the other token
operations (i.e.
crud ops).
Hubert
On Fri, May 21, 2010 at 7:05 PM, Beau
Lebens<[email protected]> wrote:
Could this just be implemented through support for a scope change
where scope=none or revoke or something?
On Friday, May 21, 2010, Lukas Rosenstock<[email protected]>
wrote:
Why not simply add this functionality to the token endpoint?The
same place that was used to fetch the access token first or refresh
it could be used to revoke the same token with another request. The
only requirement would be to define something like type=revoke.
I feel that is much easier than making the token a URL which
supports DELETE.
However, any mechanism will break implementations that rely on
minimal or no communication between authorization server and
protected resource, because all protected resources have to be
informed.
Regards, Lukas
2010/5/16 Dick Hardt<[email protected]>
James: An important capability of the refresh token is that it
*can* be a self contained token in that is not an id, but a signed
token that can be examined and acted upon on presentation.
Torsten: enabling a client to revoke a refresh token looks like a
useful mechanism. I anticipate it will be viewed as a vitamin
feature rather than a painkiller and will fall by the wayside
unless the security conscience rally to have it included.
-- Dick
On Thu, May 13, 2010 at 7:10 AM, Manger, James
H<[email protected]> wrote:
Torsten,
What about refresh token revocation/deletion?
HTTP already has a method to do this: DELETE
It just needs each token to have a URI.
Tokens (almost) already have URIs -- its just not immediately
obvious because the URI has to be built from a common token
endpoint and a refresh_token.
I think it would improve the spec if refresh_token was renamed to,
say, token_id; and its value defined as a URI (which can be a
relative URI so the string may not need to change at all).
To refresh a token you POST to the token's URI.
To delete a token you send a DELETE request to the token's URI.
It doesn't cause major changes, but there are some benefits.
It is a more web-style design.
It leaves only 1 type of token in the spec -- an access token --
which simplifies the text and aids understanding.
There are no arguments about length, allowed chars etc because it
is a URI -- a well-known type, often with native support.
Its obvious how to delete the token as there is a standard HTTP
method DELETE to apply to the token URI.
If a particular service supported an additional way to delete items
in its API (eg POST with a method=delete query parameter) that
could apply to the OAuth part as well.
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
http://lukasrosenstock.net/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
