Re: [OAUTH-WG] Refresh tokens in Security BCP -15

Am 06.04.20 um 15:59 schrieb Aaron Parecki: > Keeping the details in section 4 makes sense. I think why I was > confused is that there isn't a subheader in section 2 for refresh > tokens so it's not immediately obvious until you get to section 4. > What about adding a new subhead in section 2 with

Re: [OAUTH-WG] Refresh tokens in Security BCP -15

Keeping the details in section 4 makes sense. I think why I was confused is that there isn't a subheader in section 2 for refresh tokens so it's not immediately obvious until you get to section 4. What about adding a new subhead in section 2 with just that short summary and referring to section 4 f

Re: [OAUTH-WG] Refresh tokens

Ok thanks for the input here everyone. I'm not seeing much of a consensus, but these are all excellent points and I've collected them for discussion during the meeting on Friday. Aaron Parecki aaronparecki.com @aaronpk On Mon, Jul 22, 2019 at 8:12 AM Torsten Lo

Re: [OAUTH-WG] Refresh tokens

Hi Neil, > On 22. Jul 2019, at 13:59, Neil Madden wrote: > >> In addition, a public client which does not use its refresh token in an >> “offline” manner may have theft go unnoticed for a considerable period of >> time, and the operational model of public clients usually puts detection of >>

Re: [OAUTH-WG] Refresh tokens

Thank you both for your replies, my responses are below: On 20 Jul 2019, at 19:54, David Waite wrote: > >> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: >> >> Access tokens and refresh tokens, stored browser-side, are equally >> vulnerable to theft, because the storage options are identical

Re: [OAUTH-WG] Refresh tokens

> FWIW, in addition, those can be used together -- sliding & absolute.  Azure AD does both at this point. They used to do 90 days absolute, now it is a sliding, 72 hours by default I believe.  Good discussion overall, would this be a good summary for the type of a client the spec is for: SHOUL

Re: [OAUTH-WG] Refresh tokens

I left out Okta (how could I?) - it supports a refresh token expiration, but I couldn't find doc on the details. On Sun, Jul 21, 2019 at 10:44 AM Brock Allen wrote: > > IdentityServer allows a choice of behavior on refresh token

Re: [OAUTH-WG] Refresh tokens

> IdentityServer allows a choice of behavior on refresh token expiration time. >It can have a absolute expiration time, or use a sliding window. FWIW, in addition, those can be used together -- sliding & absolute. Finally,  refresh tokens can be re-use or one-time use only. These are all per-clie

Re: [OAUTH-WG] Refresh tokens

I did some looking around regarding the lifetime of refresh tokens in various OP services. Auth0 ,and google do not appear to support a limited lifetime on refresh t

Re: [OAUTH-WG] Refresh tokens

> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: > > Access tokens and refresh tokens, stored browser-side, are equally vulnerable > to theft, because the storage options are identical. > > We are more concerned about the theft of the refresh token, because it > (commonly) has a longer usa

Re: [OAUTH-WG] Refresh tokens

Access tokens and refresh tokens, stored browser-side, are equally vulnerable to theft, because the storage options are identical. We are more concerned about the theft of the refresh token, because it (commonly) has a longer usable lifetime than the access token. Still , its a matter of degree.

Re: [OAUTH-WG] Refresh tokens

Can somebody spell out why refresh tokens require more protection than access tokens? What threat are we worried about? The security benefits and risks of refresh tokens seem to be consistently emphasised, yet nobody seems to ever spell out exactly what they are. The main benefit is allowing t

Re: [OAUTH-WG] Refresh tokens

I think it can be as simple as: SHOULD NOT use refresh tokens without client authentication or key proof of some kind. In other words, no bearer refresh tokens. — Justin On Jul 19, 2019, at 7:49 PM, Aaron Parecki mailto:aa...@parecki.com>> wrote: So what I'm hearing in this thread is essenti

Re: [OAUTH-WG] Refresh tokens

I believe that access tokens and any refresh token policy should be guided by the user authentication process and session lifetime policy of the AS. There’s a case to be made that whether someone gets access to my access token directly or a refresh token that allows someone to grant a new access

Re: [OAUTH-WG] Refresh tokens

So what I'm hearing in this thread is essentially that: 1) depending on how it's implemented, using a refresh token in a SPA can provide security benefits over using only access tokens 2) it is still "dangerous" to allow refresh tokens to be used without client authentication 3) if there is a way

Re: [OAUTH-WG] Refresh tokens

You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof. Now if the SPA p

Re: [OAUTH-WG] Refresh tokens

> > 2. To use a refresh token at the /token endpoint, client authentication is > required. This is where it gets difficult for default SPAs because they are > public clients and the only mechanism to authenticate them is the client_id > which is itself public. For me, this is the real risk of expos

Re: [OAUTH-WG] Refresh tokens

For historical references only... the Google model around refresh tokens and the AOL model around refresh tokens were slightly different. So I proposed a bunch of the OIDC text around refresh tokens and offline access to allow for both models. At AOL, the model was that refresh_tokens were bou

Re: [OAUTH-WG] Refresh tokens

I'll just add a couple more thoughts around refresh_tokens. 1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there. 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default

Re: [OAUTH-WG] Refresh tokens

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki wrote: > > These are all very good points! I think the challenge here is figuring out > where this kind of guidance is most appropriate. > > It does seem like some of these issues are unique to a browser environment > (particularly where the browse

Re: [OAUTH-WG] Refresh tokens

These are all very good points! I think the challenge here is figuring out where this kind of guidance is most appropriate. It does seem like some of these issues are unique to a browser environment (particularly where the browser itself is managing the access and refresh tokens), so maybe it make

Re: [OAUTH-WG] Refresh tokens

> On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: > Re 8. Refresh Tokens > >"For public clients, the risk of a leaked refresh token is much >greater than leaked access tokens, since an attacker can potentially >continue using the stolen refresh token to obtain new access without >b

Re: [OAUTH-WG] refresh tokens and client instances

y Beryozkin > Sent: Thursday, July 03, 2014 9:29 AM > To: Bill Mills; oauth@ietf.org > Subject: Re: [OAUTH-WG] refresh tokens and client instances > > Hi > On 03/07/14 16:40, Bill Mills wrote: >> Implementations may/SHOULD bind refresh tokens to specific client >> ins

Re: [OAUTH-WG] refresh tokens and client instances

>>>> specific client instances. > >>>> > >>>> AFAIK refresh tokens would only go on the wire, assuming they are > >>>> supported, when a client exchanges a grant for a new access token. > >>>> And when the client uses a refresh t

Re: [OAUTH-WG] refresh tokens and client instances

u for your reply. Would appreciate if you consider my inline comments below and respond again! R, Madjid *From:*John Bradley [mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>] *Sent:*Wednesday, June 25, 2014 5:56 PM *To:*Madjid Nakhjiri *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <

Re: [OAUTH-WG] refresh tokens and client instances

>>>> Was it really about a refresh token grant where the incoming client id >>>> and refresh token pair can uniquely identify the actual client instance >>>> ? That would make sense. >>>> >>>> Something else I'd like to clarify. >&g

Re: [OAUTH-WG] refresh tokens and client instances

. Do you need different grant code types for each type of token? Thanks, Madjid -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey Beryozkin Sent: Thursday, July 03, 2014 9:29 AM To: Bill Mills; oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens and client ins

Re: [OAUTH-WG] refresh tokens and client instances

refresh token pair can uniquely identify the actual client instance >>>> ? That would make sense. >>>> >>>> Something else I'd like to clarify. >>>> John mentions a refresh token is created at the authorization grant >>>> initia

Re: [OAUTH-WG] refresh tokens and client instances

, 2014 5:56 PM *To:*Madjid Nakhjiri *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org <mailto:oauth@ietf.org>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances In 3.3 It is saying that the refresh token is a secret that the Authorization server has bound to

Re: [OAUTH-WG] refresh tokens and client instances

14, at 1:24 PM, Madjid Nakhjiri > <mailto:m.nakhj...@samsung.com> >> > <mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@samsung.com>>> wrote: >> > >> >> Hi John, >> >> Thank you for your reply. Would appreciate if you consider my inli

Re: [OAUTH-WG] refresh tokens and client instances

ain! >  >> R, >  >> Madjid >  >> *From:*John Bradley [mailto:ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>] >  >> *Sent:*Wednesday, June 25, 2014 5:56 PM >  >> *To:*Madjid Nakhjiri >  >> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> &l

Re: [OAUTH-WG] refresh tokens and client instances

gt; Thank you for your reply. Would appreciate if you consider my inline >> comments below and respond again! >> R, >> Madjid >> *From:*John Bradley [mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>] >> *Sent:*Wednesday, June 25, 2014 5:56 PM >> *T

Re: [OAUTH-WG] refresh tokens and client instances

comments below and respond again! >> R, >> Madjid >> *From:*John Bradley [mailto:ve7...@ve7jtb.com] >> *Sent:*Wednesday, June 25, 2014 5:56 PM >> *To:*Madjid Nakhjiri >> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> >> *Subject:*Re: [OAUTH-WG] refresh toke

Re: [OAUTH-WG] refresh tokens and client instances

25, 2014 5:56 PM *To:*Madjid Nakhjiri *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances In 3.3 It is saying that the refresh token is a secret that the Authorization server has bound to the client_id, that the Authorization server effect

Re: [OAUTH-WG] refresh tokens and client instances

11:22 AM To: Madjid Nakhjiri Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens and client instances Inline On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri wrote: Hi John, Thank you for your reply. Would appreciate if you consider my inline comments below and respond again

Re: [OAUTH-WG] refresh tokens and client instances

dnesday, June 25, 2014 5:56 PM > To: Madjid Nakhjiri > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] refresh tokens and client instances > > In 3.3 It is saying that the refresh token is a secret that the Authorization > server has bound to the client_id, that the Authorization ser

Re: [OAUTH-WG] refresh tokens and client instances

Hi John, Thank you for your reply. Would appreciate if you consider my inline comments below and respond again! R, Madjid From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Wednesday, June 25, 2014 5:56 PM To: Madjid Nakhjiri Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens

Re: [OAUTH-WG] refresh tokens and client instances

In 3.3 It is saying that the refresh token is a secret that the Authorization server has bound to the client_id, that the Authorization server effectively uses to differentiate between instances of that client_id. When the refresh token is generated, it can be stored in a table with the client_

Re: [OAUTH-WG] Refresh tokens

lto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Refresh tokens 1&2) Yep. This is why flows using Refresh Tokens must always use SSL. 3) Refresh tokens are comparable to access tokens in that you can scope them etc. In fact it makes a great deal of sense to limit them in the same way th

Re: [OAUTH-WG] Refresh tokens

er 28, 2011 7:20 AM Subject: Re: [OAUTH-WG] Refresh tokens I forgot the following question: 5. If refresh taken are just another way of requesting access tokens, I believe they should be specified in section 4, with other grant types. But there must be a reason for the way it is now, so why? With

Re: [OAUTH-WG] Refresh tokens

I forgot the following question: 5. If refresh taken are just another way of requesting access tokens, I believe they should be specified in section 4, with other grant types. But there must be a reason for the way it is now, so why? With kind regards, Bart Wiegmans | Developer -Oorspronkeli

Re: [OAUTH-WG] Refresh Tokens

Precisely! In fact the anonymity of this sort can be achieved even without a refresh token: as long as the end user is not required to authenticate to the client. But for all I remember, we have never had a SINGLE USE CASE (sorry to transition to my pet peeve) that required anonymity. The or

Re: [OAUTH-WG] Refresh Tokens

In some sense, but it is an indirect consequence of the fact the protocol is for granting access without requiring the revealing of user credentials, which in most (but not all) cases means hiding the user's identity on the system. In many cases however, their identity is simply translated/embodie

Re: [OAUTH-WG] Refresh Tokens

Many APIs in practice have a method such as "/me" or "/profile" for applications to retrieve the profile information of the resource owner given their access token. IMO this is a completely appropriate use of OAuth, even though the resource owner is no longer anonymous in this case. I agree that it

Re: [OAUTH-WG] Refresh Tokens

OAuth allows a client to access user resources without revealing the resource owner's identity to the client. Isn't this anonymity? I consider this an important property of the protocol. regards, Torsten. On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: This seems to need a chair to st

Re: [OAUTH-WG] Refresh Tokens

This seems to need a chair to step in. Tony is taking a strong stand and maintaining it: On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin wrote: > Nowhere in the specification is there explanation for refresh tokens, The > reason that the Refresh token was introduced was for anonymity. The scena

Re: [OAUTH-WG] Refresh Tokens

> *From:* Anthony Nadalin > *To:* Eran Hammer-Lahav > *Cc:* "OAuth WG (oauth@ietf.org)" > *Sent:* Thursday, August 11, 2011 3:45 PM > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > Disagree, this was our rational and this is one way it’s

Re: [OAUTH-WG] Refresh Tokens

> > From: Anthony Nadalin > To: Eran Hammer-Lahav > Cc: "OAuth WG (oauth@ietf.org)" > Sent: Thursday, August 11, 2011 3:45 PM > Subject: Re: [OAUTH-WG] Refresh Tokens > > Disagree, this was our rational and this is one way

Re: [OAUTH-WG] Refresh Tokens

rg>)" mailto:oauth@ietf.org>> Sent: Thursday, August 11, 2011 3:45 PM Subject: Re: [OAUTH-WG] Refresh Tokens Disagree, this was our rational and this is one way it’s used today with our scenarios. This needs to be assigned an issue. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com

Re: [OAUTH-WG] Refresh Tokens

rational and this is one way it’s used today with our scenarios. This needs to be assigned an issue. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 3:39 PM To: Anthony Nadalin Cc: Dick Hardt; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re

Re: [OAUTH-WG] Refresh Tokens

OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens   The text is wrong. This is not why refresh tokens were introduced (originally by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have no special anonymity properties.    EHL On Aug 11, 2011, at 18:18, &quo

Re: [OAUTH-WG] Refresh Tokens

uth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] Refresh Tokens 1. Process-wise it does. This is a brand new concept *here* and was not mentioned in the charter or any use cases. Therefore, out of scope. 2. The current text provides all the information needed to imement. No o

Re: [OAUTH-WG] Refresh Tokens

I’m raising the issue on the current text, I already provided text if the original append. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 3:03 PM To: Anthony Nadalin Cc: Dick Hardt; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH

Re: [OAUTH-WG] Refresh Tokens

I’m raising the issue on the current text, I already provided text if the original append. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 3:03 PM To: Anthony Nadalin Cc: Dick Hardt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens 1. Process

Re: [OAUTH-WG] Refresh Tokens

Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] Refresh Tokens That's irrelevant given WRAP does not mention anonymity or anything else about refresh token not explicitly addressed already by v2. Your email is the very first t

Re: [OAUTH-WG] Refresh Tokens

th WG (oauth@ietf.org)" Sent: Thursday, August 11, 2011 1:51 PM Subject: Re: [OAUTH-WG] Refresh Tokens There are no use cases at all in WRAP to help explain choices taken, it does not matter if there were or were not previous issues raised, it is being raised now.   From:Eran Hammer-Lahav

Re: [OAUTH-WG] Refresh Tokens

Subject: Re: [OAUTH-WG] Refresh Tokens Anonymity was certainly part of the design for WRAP   From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens   Sectio

Re: [OAUTH-WG] Refresh Tokens

: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens That's irrelevant given WRAP does not mention anonymity or anything else about refresh token not explicitly addressed already by v2. Your email is the very first time this has been raised on this list. EHL From: Anthony Na

Re: [OAUTH-WG] Refresh Tokens

11 12:41:28 -0700 To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, Dick Hardt mailto:dick.ha...@gmail.com>> Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" mailto:oauth@ietf.org>> Subject: RE: [OAUTH-WG] Refresh Tokens Anonymity was certainly part of

Re: [OAUTH-WG] Refresh Tokens

om Yaron. > > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Thursday, August 11, 2011 1:25 PM > To: Anthony Nadalin > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > If it was, no one told me. > > On 2011-08-

Re: [OAUTH-WG] Refresh Tokens

Could be! But a definite from Yaron. From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Thursday, August 11, 2011 1:25 PM To: Anthony Nadalin Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony

Re: [OAUTH-WG] Refresh Tokens

Maybe the feature was added anonymously. ;-) On 8/11/11 2:25 PM, Dick Hardt wrote: > If it was, no one told me. > > On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: > >> Anonymity was certainly part of the design for WRAP ___ OAuth mailing list OAut

Re: [OAUTH-WG] Refresh Tokens

c: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > Section 1.5 already covers refresh tokens. There are many use cases for > refresh tokens. They are basically a protocol feature used to make > scalability and security more flexible. Anonymity was never part of t

Re: [OAUTH-WG] Refresh Tokens

Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for refresh tokens. They are basically a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design

Re: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There

Re: [OAUTH-WG] Refresh Tokens

G (oauth@ietf.org<mailto:oauth@ietf.org>)" mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAu

Re: [OAUTH-WG] Refresh Tokens

security > considerations section? > > > > > __ > From: Anthony Nadalin > To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Sent: Thursday, August 11, 2011 11:15 AM > Subject: Re: [OAUTH-WG] Refresh Tokens > > Many reasons, but none are explained

Re: [OAUTH-WG] Refresh Tokens

Does it want to be in the main definition or the security considerations section? From: Anthony Nadalin To: Dick Hardt Cc: "OAuth WG (oauth@ietf.org)" Sent: Thursday, August 11, 2011 11:15 AM Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons

Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and

Re: [OAUTH-WG] Refresh Tokens

Refresh tokens have a different main goal, in my opinion.  They are useful to allow a log lived durable replacement for username/password.  This means the user's primary credential is not stored in the client.  Refresh tokens can be revoked by the user without requiring password change.  They ar

Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be revoked by not issuing new acc

Re: [OAUTH-WG] Refresh tokens

+1 Von: Brian Eaton [mailto:bea...@google.com] Gesendet: Mittwoch, 15. Juni 2011 20:33 An: Eran Hammer-Lahav Cc: OAuth WG Betreff: Re: [OAUTH-WG] Refresh tokens On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav mailto:e...@hueniverse.com>> wrote: I would like to add a quick discuss

Re: [OAUTH-WG] Refresh tokens

From: Brian Eaton > To: Eran Hammer-Lahav > Cc: OAuth WG > Sent: Wednesday, June 15, 2011 11:32 AM > > Subject: Re: [OAUTH-WG] Refresh tokens > > On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav > wrote: > I would like to add a quick discussion of access toke

Re: [OAUTH-WG] Refresh tokens

okens are credentials used to access protected > resources. Refresh > tokens are credentials used to obtain access tokens. > > -bill > > > -- > *From:* Brian Eaton > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Sent:* Wednesday, June 15, 201

Re: [OAUTH-WG] Refresh tokens

-bill From: Brian Eaton To: Eran Hammer-Lahav Cc: OAuth WG Sent: Wednesday, June 15, 2011 11:32 AM Subject: Re: [OAUTH-WG] Refresh tokens On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav wrote: I would like to add a quick discussion of access token and refresh

Re: [OAUTH-WG] Refresh tokens

an Hammer-Lahav Cc: Brian Eaton; OAuth WG Subject: Re: [OAUTH-WG] Refresh tokens There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the &quo

Re: [OAUTH-WG] Refresh tokens

There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-t

Re: [OAUTH-WG] Refresh tokens

: Brian Eaton [mailto:bea...@google.com] Sent: Wednesday, June 15, 2011 11:33 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh tokens On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav mailto:e...@hueniverse.com>> wrote: I would like to add a quick discussion of access tok

Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav wrote: > I would like to add a quick discussion of access token and refresh token > recommended deployment setup, providing clear guidelines when a refresh > token SHOULD and SHOULD NOT be issued, and when issues, how it is difference > from the

Re: [OAUTH-WG] Refresh tokens security enhancement

esh token. > > > > EHL > > > > > >> -Original Message- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Wednesday, May 05, 2010 12:28 PM > >> To: Marius

Re: [OAUTH-WG] Refresh tokens security enhancement

, 2010 12:28 PM To: Marius Scurtescu Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh tokens security enhancement Am 04.05.2010 21:44, schrieb Marius Scurtescu: On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt wrote: Am 03.05.2010 18:55, schrieb Allen Tom

Re: [OAUTH-WG] Refresh tokens security enhancement

age- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, May 05, 2010 12:28 PM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh tokens security enhancement > > Am 04.05

Re: [OAUTH-WG] Refresh tokens security enhancement

Am 04.05.2010 21:44, schrieb Marius Scurtescu: On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt wrote: Am 03.05.2010 18:55, schrieb Allen Tom: Invalidating the Refresh Token (and presumably also invalidating any outstanding Access Tokens) would make sense as an option for applic

Re: [OAUTH-WG] Refresh tokens security enhancement

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt wrote: > Am 03.05.2010 18:55, schrieb Allen Tom: >> Invalidating the Refresh Token (and presumably also invalidating any >> outstanding Access Tokens) would make sense as an option for applications >> that require a high level of security. Howev

Re: [OAUTH-WG] Refresh tokens security enhancement

Hi Allen, Am 03.05.2010 18:55, schrieb Allen Tom: Hi Torsten, Thanks for posting this idea - I think that issuing a new Refresh Token (and invalidating the old one) on every refresh request would help detect token theft. HOWEVER - in practice, this mechanism could make implementations very tri

Re: [OAUTH-WG] Refresh tokens security enhancement

Hi Torsten, Thanks for posting this idea - I think that issuing a new Refresh Token (and invalidating the old one) on every refresh request would help detect token theft. HOWEVER - in practice, this mechanism could make implementations very tricky. For example, some applications are highly distr