This is exactly my contention with using DELETE: it's specified[1] as
deleting the resource identified by the URI, and it's not meant as way
to determine intended action in a higher-level API. Like PUT, it's there
for using HTTP as a uri-addressable document store. I'm also not
convinced it's going
> Since refresh token is only issued to clients capable of directly interacting
> with the authorization server, is there a reason why the endpoint cannot use
> DELETE instead of a POST with a parameter?
>
> DELETE /token HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-fo
sage-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, June 14, 2010 11:30 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] in-app logout?
>
>
>
> Am 14.06.2010 19:10, schrieb Eran Hammer-Lahav:
> > Not
I think both options are reasonable.
regards,
Torsten.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, May 26, 2010 11:26 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] in-app logout?
Hi Eran,
i
26, 2010 11:26 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] in-app logout?
>
> 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 sp
I'm 135 messages behind on the list. I'm knee deep in -07.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, June 11, 2010 10:03 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Fwd: Re: [OAUTH-WG] in-app logout?
Hi Eran,
you probably didn&#
+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
speci
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/re
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 wrote:
> Could this just be implemented through support for a scope change
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 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 c
+1
There are many examples in production of token authentication schemes that
have a ³revoke token² API for clients to voluntarily revoke their own
credentials.
Examples:
Google¹s AuthSubRevokeToken:
http://code.google.com/apis/accounts/docs/AuthSub.html#AuthSubRevokeToken
OAuth Session Exten
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 ma
I agree token management is important. It actually can (and sometimes
must) go farther than token deletion/revocation. For instance, adding the
possibility for the resource owner (or others with appropriate rights) of
"inspecting" released tokens etc. Kind of like what UMA is getting at.
At the pr
On Sun, May 16, 2010 at 11:27 AM, Dick Hardt wrote:
> 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
May 2010 10:27 AM
To: Manger, James H
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] in-app logout?
On 2010-05-16, at 5:20 PM, Manger, James H wrote:
> Dick,
>
>> James: An important capability of the refresh token is that it *can* be a
>> self contained token in that
: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Dick Hardt
> Sent: Sunday, May 16, 2010 5:27 PM
> To: Manger, James H
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] in-app logout?
>
>
> On 2010-05-16, at 5:20 PM, Manger, James H wrote:
>
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] in-app logout?
>
>
> On 2010-05-16, at 5:20 PM, Manger, James H wrote:
>
> > Dick,
> >
> >> James: An important capability of the refresh token is that it *can* be a
> self contained token in that is
On 2010-05-16, at 5:20 PM, Manger, James H wrote:
> Dick,
>
>> 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.
>
> Defining refresh_token as a URI
Dick,
> 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.
Defining refresh_token as a URI does not prevent it being a self-contained
signed token.
The
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 v
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.
OAuth currently focues on the issuance and usage of tokens.
What about refresh token revocation/deletion?
Several mobile apps today use long-living tokens as a means to log in to
services. They typically also offer a button to log-off/log-out, which
cause the app to delete the token from the d
22 matches
Mail list logo
