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

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

I believe the document would flow better if section 4.12 about Refresh Tokens were moved into section 2. The Refresh Token section contains descriptions of some pretty significant normative behavior, and I worry that it will get lost in the long list of attacks and mitigations. Section 2 starts

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

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

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:

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

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

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

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

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

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

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

> > 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

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

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

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

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

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 >

[OAUTH-WG] Refresh tokens

Ok, I'm creating a new posting for this feedback. :) Here's where I probably just need some enlightenment, so please help me out. 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

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

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 the client_id, that the Authorization server effectively uses to differentiate between instances

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

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 mailto:oauth@ietf.org mailto:oauth@ietf.org *Subject:*Re: [OAUTH-WG

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

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 instances Hi On 03

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

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 the client_id, that the Authorization

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

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 mailto:oauth@ietf.org mailto:oauth@ietf.org *Subject:*Re: [OAUTH-WG] refresh tokens and client

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

...@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 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

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

: [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 instances. Yes, it's possible that the client ID with dynamic registration is unique to each client, but many of the token theft use

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 effectively uses

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

! 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 tokens and client instances In 3.3 It is saying that the refresh token is a secret

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

*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 mailto:oauth@ietf.org mailto:oauth@ietf.org *Subject:*Re: [OAUTH-WG] refresh tokens and client instances In 3.3

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

,   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 mailto:oauth@ietf.org mailto:oauth@ietf.org   *Subject:*Re: [OAUTH-WG] refresh tokens and client

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

*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 mailto:oauth@ietf.org mailto:oauth@ietf.org *Subject:*Re: [OAUTH-WG] refresh tokens and client instances In 3.3

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

, 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 server effectively uses to differentiate

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 m.nakhj...@samsung.com wrote: Hi John, Thank you for your reply. Would appreciate if you consider my inline comments below

[OAUTH-WG] Refresh tokens

Hello everybody, This is my first post on this mailing list, so I will introduce myself. My name is Bart Wiegmans, I work in Groningen, the Netherlands. I am involved with OAuth2 because I am implementing an authorization server for my employer, all4students / studenten.net. I have few remarks

Re: [OAUTH-WG] Refresh tokens

-Oorspronkelijk bericht- Van: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Namens Bart Wiegmans Verzonden: maandag 28 november 2011 16:13 Aan: oauth WG Onderwerp: [OAUTH-WG] Refresh tokens Hello everybody, This is my first post on this mailing list, so I will introduce myself. My name is Bart

Re: [OAUTH-WG] Refresh tokens

: Monday, November 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

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

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's

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

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

[OAUTH-WG] Refresh Tokens

Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the client the user's identity. By issuing the

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

Re: [OAUTH-WG] Refresh Tokens

(oauth@ietf.org) oauth@ietf.org Sent: Thursday, August 11, 2011 10:40 AM Subject: [OAUTH-WG] Refresh Tokens Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user

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

Re: [OAUTH-WG] Refresh Tokens

: [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

Re: [OAUTH-WG] Refresh Tokens

...@gmail.com Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto: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

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

Re: [OAUTH-WG] Refresh Tokens

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

) 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, and by the nature

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

Aug 2011 12:41:28 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: RE: [OAUTH-WG] Refresh Tokens Anonymity

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 Nadalin tony

Re: [OAUTH-WG] Refresh Tokens

...@hueniverse.com; Dick Hardt dick.ha...@gmail.com Cc: OAuth WG (oauth@ietf.org) 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

Re: [OAUTH-WG] Refresh Tokens

To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.orgmailto: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

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

:[mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 1:46 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens That's irrelevant given WRAP does not mention anonymity or anything else about refresh

Re: [OAUTH-WG] Refresh Tokens

: [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, Anthony Nadalin tony...@microsoft.commailto:tony

Re: [OAUTH-WG] Refresh Tokens

: 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] Sent: Thursday, August 11, 2011 3:39 PM

Re: [OAUTH-WG] Refresh Tokens

; OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto: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

Re: [OAUTH-WG] Refresh Tokens

@ietf.orgmailto: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] Sent

Re: [OAUTH-WG] Refresh Tokens

tony...@microsoft.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG (oauth@ietf.org) 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

Re: [OAUTH-WG] Refresh Tokens

*To:* Eran Hammer-Lahav e...@hueniverse.com *Cc:* OAuth WG (oauth@ietf.org) 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

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 tony...@microsoft.com wrote: Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for

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 e...@hueniverse.commailto:e...@hueniverse.com wrote: I would like to add a quick

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 e...@hueniverse.commailto:e...@hueniverse.com wrote: I would like to add a quick discussion

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

Re: [OAUTH-WG] Refresh tokens

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 an access token good

Re: [OAUTH-WG] Refresh tokens

From: Brian Eaton bea...@google.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org 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 e...@hueniverse.com wrote: I

Re: [OAUTH-WG] Refresh tokens

*Subject:* Re: [OAUTH-WG] Refresh tokens On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav e...@hueniverse.comwrote: 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

Re: [OAUTH-WG] Refresh tokens security enhancement

: 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.2010 21:44, schrieb Marius Scurtescu

Re: [OAUTH-WG] Refresh tokens security enhancement

The text is in -04. -02 made the refresh token available in token refresh. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, May 09, 2010 2:57 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh tokens

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 tors...@lodderstedt.net 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

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

Re: [OAUTH-WG] Refresh tokens security enhancement

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt tors...@lodderstedt.net 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

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

[OAUTH-WG] Refresh tokens security enhancement

Hi all, I discussed OAuth with some of the security experts here at Deutsche Telekom. We came up w/ an idea for enhancing refresh token handling I would like to discuss in the WG. Assumption: refresh tokens have a very long duration (month to unlimited) and are stored at the client in a