Re: [OAUTH-WG] Lifetime of refresh token
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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Lifetime of refresh token
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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Lifetime of refresh token
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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Lifetime of refresh token
One viable method for detecting “inactivity for one month” would be to have a one month expiration on the refresh token, but reset that counter every time the refresh token is used to get a new access token. You can do this by manipulating the expiration of the token object itself on your authorization server, or you can just throw away the old refresh token and create a new one with an expiration one month out. Each of these methods has its benefits and pitfalls. — Justin On Aug 28, 2015, at 10: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 mailto: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 mailto: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 mailto: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 mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth 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
Re: [OAUTH-WG] Lifetime of refresh token
This is all contextual to the application. In some situations I want to immediately force re-authentication for all transactions above X$ such as banking applications. In some situations I want a permanent refresh token, like for Twitter like social applications. etc...etc... - Jim Manico On 8/28/15 10:58 AM, William Denniss wrote: +1 for John's suggestion. Why force users to re-authenticate after an arbitrary 30-day window? On Fri, Aug 28, 2015 at 1:41 PM John Bradley ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com wrote: I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the refresh token. Rolling the refresh token also has the advantage that if the token leaks or is stollen then you will detect the second use of the expired refresh token and invalidate both, so the user needs to loggin. In general I think rolling the refresh token is a good idea though it is not popular, I think it is more secure. John B. On Aug 28, 2015, at 11:21 AM, Donghwan Kim flowersinthes...@gmail.com mailto: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 mailto: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 mailto: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 mailto: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
Re: [OAUTH-WG] Lifetime of refresh token
Again, I would state that this is all contextual to the application being built - which is why the RFC never gives specific times other than short lived or long lived. I would suggest giving a series of recommendations relative to a few different risk profiles (low risk, social media, banking, enterprise, etc) as opposed to one recommendation. With respect, Jim Manico On 8/28/15 10:41 AM, John Bradley wrote: I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the refresh token. Rolling the refresh token also has the advantage that if the token leaks or is stollen then you will detect the second use of the expired refresh token and invalidate both, so the user needs to loggin. In general I think rolling the refresh token is a good idea though it is not popular, I think it is more secure. John B. On Aug 28, 2015, at 11:21 AM, Donghwan Kim flowersinthes...@gmail.com mailto: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 mailto: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 mailto: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 mailto: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).
Re: [OAUTH-WG] Lifetime of refresh token
I stand corrected, the RFC does give specific time recommendations such as 10 minutes authorization code recommendation here https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall point is still valid. :) Aloha, Jim On 8/28/15 11:36 AM, Jim Manico wrote: Again, I would state that this is all contextual to the application being built - which is why the RFC never gives specific times other than short lived or long lived. I would suggest giving a series of recommendations relative to a few different risk profiles (low risk, social media, banking, enterprise, etc) as opposed to one recommendation. With respect, Jim Manico On 8/28/15 10:41 AM, John Bradley wrote: I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the refresh token. Rolling the refresh token also has the advantage that if the token leaks or is stollen then you will detect the second use of the expired refresh token and invalidate both, so the user needs to loggin. In general I think rolling the refresh token is a good idea though it is not popular, I think it is more secure. John B. On Aug 28, 2015, at 11:21 AM, Donghwan Kim flowersinthes...@gmail.com mailto: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 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
Re: [OAUTH-WG] Lifetime of refresh token
+1 for John's suggestion. Why force users to re-authenticate after an arbitrary 30-day window? On Fri, Aug 28, 2015 at 1:41 PM John Bradley ve7...@ve7jtb.com wrote: I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the refresh token. Rolling the refresh token also has the advantage that if the token leaks or is stollen then you will detect the second use of the expired refresh token and invalidate both, so the user needs to loggin. In general I think rolling the refresh token is a good idea though it is not popular, I think it is more secure. John B. On Aug 28, 2015, at 11: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 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 ___ 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
Re: [OAUTH-WG] Lifetime of refresh token
I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is what you want for a inactivity timeout after which the user must authenticate again. The user can always revoke the refresh token. Rolling the refresh token also has the advantage that if the token leaks or is stollen then you will detect the second use of the expired refresh token and invalidate both, so the user needs to loggin. In general I think rolling the refresh token is a good idea though it is not popular, I think it is more secure. John B. On Aug 28, 2015, at 11: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 mailto: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 mailto: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 mailto: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 mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature
[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename: draft-ietf-oauth-proof-of-possession-04.txt Pages : 16 Date: 2015-08-28 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments
Proof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining working group comments received - both a few leftover WGLC comments and comments received during IETF 93 in Praguehttp://www.ietf.org/meeting/93/. The changes were: * Allowed the use of jwk for symmetric keys when the JWT is encrypted. * Added the jku (JWK Set URL) member. * Added privacy considerations. * Reordered sections so that the cnf (confirmation) claim is defined before it is used. * Noted that applications can define new claim names, in addition to cnf, to represent additional proof-of-possession keys, using the same representation as cnf. * Applied wording clarifications suggested by Nat Sakimura. The updated specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-04.html -- Mike P.S. This note was also published at http://self-issued.info/?p=1442 and as @selfissuedhttps://twitter.com/selfissued. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?
This was added at the end of Section 3.2 in -04http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04. Thanks again for the practical feedback, Brian! -- Mike From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Tuesday, August 11, 2015 4:05 PM To: Mike Jones Cc: Brian Campbell; oauth Subject: Re: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay? OK On Aug 11, 2015, at 12:57 AM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: As discussed in the thread “[OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)”, I will update the draft to say that the symmetric key can be carried in the “jwk” element in an unencrypted form if the JWT is itself encrypted. This will happen in -04. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Sunday, March 22, 2015 11:41 PM To: oauth Subject: [OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay? When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02
Thanks again for your detailed review, Nat. The remainder of the issues you raised are addressed in the -04 drafthttp://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04. Replies are inline prefixed by Mike … From: Nat Sakimura [mailto:sakim...@gmail.com] Sent: Tuesday, August 18, 2015 9:00 PM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 Inline: 2015-08-11 14:12 GMT+09:00 Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com: Replies inline… From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, March 25, 2015 6:38 AM To: oauth Subject: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 Dear OAuthers: Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02 Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=3S7krqi0KCDTpgN8bOMXakqMNwsxVka24mvUqB8uWjE%3d Abstract It is probably better to spell out that this document is describing the JWT format that can be used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier for the reader to understand what this document aims at. It does not seem to me that the “Sender Constraint” concept described in 5.3 of [POPA] is the same 5.2 I guess, not 5.3. thing as identifying a proof-of-possession key within a JWT, which is the purpose of this specification. In this specification, the issuer makes a statement that the presenter can confirm possession of a key. I don’t know how that would map into a “Sender Constraint”. For one thing, which party are you considering to be the “Sender”? Accordingly, I left the abstract unchanged. OK. Since the draft was titled Proof of Possession Semantics for for JSON Web Tokens (JWTs), I pointed it out that it should not only talk about 5.3 of [POPA] but also 5.2. However, now that you have changed the tile to Proof of Possession KEY Semantics for for JSON Web Tokens (JWTs), this issue is resolved. It would be nice to state that it is talking about 5.3 of [POPA] in the introduction though. Mike I have added this to the introduction in response to your comment: “See xref target=I-D.ietf-oauth-pop-architecture/ for a further discussion of key confirmation.” Accordingly, we should consider the title change to something like: JWT Sender Confirmation Token Syntax OR borrowing from the financial concept which I believe is the origin of the concept of bearer token, JWT Registered Token Syntax -- here, Registered mean that either the sender constraint or key confirmation is registered within or in conjunction with the token. I changed the title in -03 to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” to make it clear this draft is about PoP key semantics for JWTs – not the proof-of-possession mechanism itself. I’ve already responded to the “Sender Constraint” suggestion above. Per my earlier response, I don’t believe that “Registered Token” is standard terminology, and so would confuse more than it would clarify. Now that you have clarified that this document is only about 5.3 of [POPA], the title in -03 is appropriate. NOTE: Registered * is a very well established term in financial industry, describing kind of token needed to be presented to exercise the right assigned to it. e.g., Registered Security, Registered Share Certificate, etc. 1. Introduction == Consider referencing draft-ietf-oauth-pop-architecture. It will be clearer for the reader then, and the text will be shorter. Again, I suspect you’re asking me to reference this draft for the “Sender Constraint” terminology, which is both vaguely defined in [POPA], and doesn’t match what this specification does. Therefore, I did not do this here, although other appropriate references to [POPA] are included. It would be nice to point out that this document is talking about the model presented in 5.3 of [POPA]. My suggestion: Insert , as described in section 5.3 of [POPA] before the end of the Para 1. This specification defines how to express a declaration in a JSON Web Token (JWT) [JWT] that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key, as described in section 5.3 of [POPA]. Mike As noted earlier, I have added this to the introduction in response to your comment: “See xref target=I-D.ietf-oauth-pop-architecture/ for a further discussion of key
