cloudcomputing general copyright1997, SungHan Kim 김성한 sunghan_...@icloud.com Global Root CA RFC-822:uspto.gov@digitalsign.email CA SHA1 hash Digital Algorithm First Used CAR eunjujang9...@gmail.com sungha...@example..com gloomysta...@msn.com umyan...@gmail.com(rsa) gloom...@gmail.com(sha1) digitalsignem...@gmail.com(connectRFC-822) 2024년 11월 14일 전달된 메시지 시작: 보낸 사람: oauth-requ...@ietf.org 날짜: 2015년 8월 29일 오전 12시 15분 1초 GMT+9 받는 사람: oauth@ietf.org 제목: OAuth Digest, Vol 82, Issue 47 답장받는 사람: oauth@ietf.org Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-requ...@ietf.org You can reach the person managing the list at oauth-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Lifetime of refresh token (Torsten Lodderstedt) 2. Re: Lifetime of refresh token (Donghwan Kim) 3. Re: Lifetime of refresh token (Bill Mills) ---------------------------------------------------------------------- Message: 1 Date: Fri, 28 Aug 2015 10:43:52 +0200 From: Torsten Lodderstedt <tors...@lodderstedt.net> To: John Bradley <ve7...@ve7jtb.com>, Donghwan Kim <flowersinthes...@gmail.com> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Lifetime of refresh token Message-ID: <c44c21e6-2559-4099-8b21-3544de896...@lodderstedt.net> Content-Type: text/plain; charset="utf-8" Refresh tokens are also used by public clients, e.g. native apps. OIDC allows to acquire a new id token from a refresh token as well. Note: this does not mean a fresh authentication but a refreshed id token containing the data of the original authentication transaction. Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <ve7...@ve7jtb.com>: > I think Nat?s diagram about the problems of doing pseudo authentication > with OAuth is being taken out of context. > > The refresh token dosen?t expire, it is revoked by the user or system. > In some cases refresh tokens are automatically revoked if the users > session to the AS ends. I think AOL typically revokes refresh tokens > when sessions terminate. > > OpenID Connect provides a separate id_token with a independent lifetime > from the refresh token. A client may keep a refresh token for a much > longer time than the user has a login session with the AS. > > Refresh tokens are typically used by confidential clients that are > using a client secret in combination with the refresh token for getting > a new access token. > > By design access tokens should be short lived as the AS is expected to > have a way of revoking refresh tokens but not access tokens. > A access token that dosen't expire , and can?t be revoked is not a good > idea. > > John B. > > >> On Aug 24, 2015, at 2:41 AM, Donghwan Kim > <flowersinthes...@gmail.com> wrote: >> >> Hi, >> >> According to Figure 2 from > http://tools.ietf.org/html/rfc6749#section-1.5 > <http://tools.ietf.org/html/rfc6749#section-1.5>, refresh token can be > used to refresh an expired access token without requesting resource > owner to sign in again (uncomfortable experience). However, if it's > true, isn't it that refresh token might be used to request a new access > token even years later? and then isn't refresh token the same with > access token which never expires? >> >> I intended to use refresh token to implement persistent login by > sending a refresh request before issued access token expires > (expires_in runs out). But if refresh token works even if access token > expired already, sending a refresh request on application start up > would be enough. >> >> So I'm not sure what I'm missing about refresh token as well as how > to implement persistent login using it (you can regard authentication > here pseudo-authentication illustrated in > https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg > <https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg>). > What is the lifetime of refresh token? >> >> Thanks, >> >> -- Donghwan >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20150828/12451300/attachment.html> ------------------------------ Message: 2 Date: Fri, 28 Aug 2015 23:21:41 +0900 From: Donghwan Kim <flowersinthes...@gmail.com> To: Torsten Lodderstedt <tors...@lodderstedt.net> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Lifetime of refresh token Message-ID: <cambdefsu0xaqvcr2+ako4pbsokeezlwgizj4dvskmay_dxm...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I'm sorry to introduce a common topic. As John has suggested, I'm going to design that * An access token should be short lived e.g. 5 minutes (not to hit the AS to verify the token or 1 hour (to hit the AS to verify the token). I'm inclined to 5 minutes for stateless architecture of RSs. * A refresh token should have 1 month of expiration time by default. If it turns out that some access token expired, its refresh token should refresh the token. Then, so called persistent login can be implemented regardless of the form of authentication. Only if it fails for some reason e.g. token revocation or inactivity for 1 month, a user is logged out automatically and should log in again. * A refresh token should be able to be revoked somehow. With 5 minutes approach, it will invalidate only the refresh token (Yes the attacker can have 5 minutes at most), and with 1 hour approach, it will invalidate the refresh token as well as the corresponding access token. Thanks, -- Donghwan On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Refresh tokens are also used by public clients, e.g. native apps. OIDC > allows to acquire a new id token from a refresh token as well. Note: this > does not mean a fresh authentication but a refreshed id token containing > the data of the original authentication transaction. > > Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <ve7...@ve7jtb.com >> : >> >> I think Nat?s diagram about the problems of doing pseudo authentication >> with OAuth is being taken out of context. >> >> The refresh token dosen?t expire, it is revoked by the user or system. >> In some cases refresh tokens are automatically revoked if the users session >> to the AS ends. I think AOL typically revokes refresh tokens when sessions >> terminate. >> >> OpenID Connect provides a separate id_token with a independent lifetime >> from the refresh token. A client may keep a refresh token for a much >> longer time than the user has a login session with the AS. >> >> Refresh tokens are typically used by confidential clients that are using >> a client secret in combination with the refresh token for getting a new >> access token. >> >> By design access tokens should be short lived as the AS is expected to >> have a way of revoking refresh tokens but not access tokens. >> A access token that dosen't expire , and can?t be revoked is not a good >> idea. >> >> John B. >> >> >> On Aug 24, 2015, at 2:41 AM, Donghwan Kim <flowersinthes...@gmail.com> >> wrote: >> >> Hi, >> >> According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5, >> refresh token can be used to refresh an expired access token without >> requesting resource owner to sign in again (uncomfortable experience). >> However, if it's true, isn't it that refresh token might be used to request >> a new access token even years later? and then isn't refresh token the same >> with access token which never expires? >> >> I intended to use refresh token to implement persistent login by sending >> a refresh request before issued access token expires (expires_in runs out). >> But if refresh token works even if access token expired already, sending a >> refresh request on application start up would be enough. >> >> So I'm not sure what I'm missing about refresh token as well as how to >> implement persistent login using it (you can regard authentication here >> pseudo-authentication illustrated in >> https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg). >> What is the lifetime of refresh token? >> >> Thanks, >> >> -- Donghwan >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> ------------------------------ >> >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20150828/9142f7e2/attachment.html> ------------------------------ Message: 3 Date: Fri, 28 Aug 2015 15:14:54 +0000 (UTC) From: Bill Mills <wmills_92...@yahoo.com> To: Donghwan Kim <flowersinthes...@gmail.com>, Torsten Lodderstedt <tors...@lodderstedt.net> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Lifetime of refresh token Message-ID: <311612966.2262095.1440774894499.javamail.ya...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" You don't need to put an expiration on the refresh token. ?You get to see that refresh token every 5 minutes anyway. ?If you ever want to force the client to re-auth just use policy on the AS. ?Nothing will be broken with what you are doing though. On Friday, August 28, 2015 7:21 AM, Donghwan Kim <flowersinthes...@gmail.com> wrote: I'm sorry to introduce a common topic. As John has suggested, I'm going to design that? * An access token should be short lived e.g. 5 minutes (not to hit the AS to verify the token or 1 hour (to hit the AS to verify the token). I'm inclined to 5 minutes for stateless architecture of RSs.* A refresh token should have 1 month of expiration time by default. If it turns out that some access token expired, its refresh token should refresh the token. Then, so called persistent login can be implemented regardless of the form of authentication. Only if it fails for some reason e.g. token revocation or inactivity for 1 month, a user is logged out automatically and should log in again.* A refresh token should be able to be revoked somehow. With 5 minutes approach, it will invalidate only the refresh token (Yes the attacker can have 5 minutes at most), and with 1 hour approach, it will invalidate the refresh token as well as the corresponding access token. Thanks, -- Donghwan On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: Refresh tokens are also used by public clients, e.g. native apps. OIDC allows to acquire a new id token from a refresh token as well. Note: this does not mean a fresh authentication but a refreshed id token containing the data of the original authentication transaction. Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <ve7...@ve7jtb.com>: I think Nat?s diagram about the problems of doing pseudo authentication with OAuth is being taken out of context. The refresh token dosen?t expire, it is revoked by the user or system.? In some cases refresh tokens are automatically revoked if the users session to the AS ends.? I think AOL typically revokes refresh tokens when sessions terminate. OpenID Connect provides a separate id_token with a independent lifetime from the refresh token.? A client may keep a refresh token for a much longer time than the user has a login session with the AS. Refresh tokens are typically used by confidential clients that are using a client secret in combination with the refresh token for getting a new access token. By design access tokens should be short lived as the AS isexpected to have a way of revoking refresh tokens but not access tokens.A access token that dosen't expire , and can?t be revoked is not a good idea. John B. On Aug 24, 2015, at 2:41 AM, Donghwan Kim <flowersinthes...@gmail.com> wrote: Hi, According to Figure 2 from?http://tools.ietf.org/html/rfc6749#section-1.5, refresh token can be used to refresh an expired access token without requesting resource owner to sign in again (uncomfortable experience). However, if it's true,isn't it that refresh token might be used to request a new access token even years later? and then isn't refresh token the same with access token which never expires? I intended to use refresh token to implement persistent login by sending a refresh request before issued access token expires (expires_in runs out). But if refresh token works even if access token expired already, sending a refresh request on application start up would be enough. So I'm not sure what I'm missing about refresh token as well as how to implement persistent login using it (you can regard authentication here pseudo-authentication illustrated in https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg). What is the lifetime of refreshtoken? Thanks, -- Donghwan_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20150828/7970b317/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 82, Issue 47 *************************************
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
