Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
I might suggest that neither of those are really best current practice per se. Using key constrained tokens is more of an aspirational recommendation for what would be good security practice than it is something that's done much for real in practice today. On Sat, Nov 17, 2018, 4:07 AM Torsten Lodderstedt > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which is still some time off)? > > Sure. That’s why the Security BCP recommends use of TLS-based methods for > sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as > Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) > are the options available. > > > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Hi Tomek, > Am 16.11.2018 um 13:59 schrieb Tomek Stojecki : > > >> The AS can bind the lifetime of the refresh tokens to the session > >> lifetime, i.e. automatically revoke it on logout. > > > Yea, I saw your other email asking about refresh token revocation relating > > to session management. Obviously for certain clients, this won't make > > sense, but for implicit/browser-based ones it's a nice feature to have. > > I agree that this can be useful, however with where we are today, is this > supported by auth servers such that it can distinguish offline from > renewable-online clients and only revoke the latter when logging out? See other thread on refresh token revocation on logout. There seems to be some implementations. Basically, I don’t think the clients needs to now because it always needs to be prepared to handle invalid (invalidated) refresh tokens (see https://tools.ietf.org/html/rfc6749#section-5.2). > > > The alternative, as you mentioned, is to not issue refresh tokens and do > > token renewal the "same old way" via iframe with prompt=none, while still > > using code flow. > > Going from Implicit to Code deals with the problem of sending RT in the URL, > which I agree is a plus. Have you taken a look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2? It gives all the justification. > Is there anything else in a way of an improvement? I still am not comfortable > enough with the idea of releasing RTs to the browser clients where it can't > be encrypted, prone to xss, etc… As already stated. The AS is not required to issue refresh tokens. If the AS decides to issue refresh tokens, there are ways to protect the refresh token from replay even for public clients. To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012. An emerging alternative is to use Token Binding (in browser) or Mutual TLS (other clients) to bind the refresh token to the client’s key key pair. kind regards, Torsten. > > > -Tomek > > On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen > wrote: > > > > It still lacks the ability to issue sender constraint access tokens. > > So you mean at the resource server ensuring the token was really issued to > the client? Isn't that an inherent limitation of all bearer tokens (modulo > HTTP token binding, which is still some time off)? Resource servers don't > know the flow the clients might use, especially if/when they have many > clients. > > > The AS can bind the lifetime of the refresh tokens to the session lifetime, > > i.e. automatically revoke it on logout. > > Yea, I saw your other email asking about refresh token revocation relating to > session management. Obviously for certain clients, this won't make sense, but > for implicit/browser-based ones it's a nice feature to have. > > The alternative, as you mentioned, is to not issue refresh tokens and do > token renewal the "same old way" via iframe with prompt=none, while still > using code flow. > > > The only potential „baby step“ I would see is to move towards „token > > id_token“. Since this requires signature/at_hash checks etc. I doubt this > > is really easier than moving to code and exchange the code for an access > > token. What’s your opinion? > > Even since OIDC arrived, this is the only flow I use for JS/browser-based > clients (anything less has always seemed so obviously inferior). So for me > and my customers, all browser-based clients I am involved in are already > there. Perhaps this is the reason for all of my questions/comments about the > recent BCP doc. Given "id_token token", CSP, and using the browser history > API to wipe the access token from browser history, we already have a decent > set of tools to mitigate attacks. As I already conceded, the only remaining > issue (IMO) is the short window of time the access token is in the URL. > > Given that it seems to me that OIDC and OAuth2 are typically used together > (at least when a user is involved with authentication), I always wonder why > the OAuth and OIDC WGs are separate. Given that so much effort of the two > sets of specs overlap, it seems odd to keep adding onto the OAuth specs and > ignoring the added features that OIDC provides. I don't mean to derail this > thread, or step on any political toes, so apologies in advance. > > > -Brock > > ___ > OAuth
Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Hi Nat, > Am 16.11.2018 um 10:12 schrieb n-sakimura : > > Good points. > > > > Also, while it may be off-topic, I do see values in implicit flows. In some > cases, such as when the AS is inside the firewall or on a localhost (e.g., > smartphone), “code flow” is not possible as the client cannot reach the AS > directly. are you saying the browser can send the HTTP GET to the authorization endpoint but the JS in the browser cannot send the HTTP POST to the token endpoint? > Banning implicit (and thus “token id_token” as well) has this repercussion First of all we are not banning anything. The OAuth WG does no longer recommend to use the implicit for very good reasons, which can be found here https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#rfc.section.2.1.2 I would appreciate your comments. > and I would not agree to it. As you were always on the „make it secure“ side, I’m a bit surprised. kind regards, Torsten. > > > > Best, > > > > Nat Sakimura > > > > From: OAuth On Behalf Of Brock Allen > Sent: Friday, November 16, 2018 7:01 AM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > > > > > It still lacks the ability to issue sender constraint access tokens. > > > > So you mean at the resource server ensuring the token was really issued to > the client? Isn't that an inherent limitation of all bearer tokens (modulo > HTTP token binding, which is still some time off)? Resource servers don't > know the flow the clients might use, especially if/when they have many > clients. > > > > > The AS can bind the lifetime of the refresh tokens to the session lifetime, > > i.e. automatically revoke it on logout. > > > > Yea, I saw your other email asking about refresh token revocation relating to > session management. Obviously for certain clients, this won't make sense, but > for implicit/browser-based ones it's a nice feature to have. > > > > The alternative, as you mentioned, is to not issue refresh tokens and do > token renewal the "same old way" via iframe with prompt=none, while still > using code flow. > > > > > The only potential „baby step“ I would see is to move towards „token > > id_token“. Since this requires signature/at_hash checks etc. I doubt this > > is really easier than moving to code and exchange the code for an access > > token. What’s your opinion? > > > > Even since OIDC arrived, this is the only flow I use for JS/browser-based > clients (anything less has always seemed so obviously inferior). So for me > and my customers, all browser-based clients I am involved in are already > there. Perhaps this is the reason for all of my questions/comments about the > recent BCP doc. Given "id_token token", CSP, and using the browser history > API to wipe the access token from browser history, we already have a decent > set of tools to mitigate attacks. As I already conceded, the only remaining > issue (IMO) is the short window of time the access token is in the URL. > > > > Given that it seems to me that OIDC and OAuth2 are typically used together > (at least when a user is involved with authentication), I always wonder why > the OAuth and OIDC WGs are separate. Given that so much effort of the two > sets of specs overlap, it seems odd to keep adding onto the OAuth specs and > ignoring the added features that OIDC provides. I don't mean to derail this > thread, or step on any political toes, so apologies in advance. > > > > > > -Brock > > > smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Hi Brock, > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > It still lacks the ability to issue sender constraint access tokens. > > So you mean at the resource server ensuring the token was really issued to > the client? Isn't that an inherent limitation of all bearer tokens (modulo > HTTP token binding, which is still some time off)? Sure. That’s why the Security BCP recommends use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available. > Resource servers don't know the flow the clients might use, especially > if/when they have many clients. They don’t need to. All they need to know is how to determine whether the sender of the token is the legit client. This is achieved by comparing the hash of the token binding id or the cert of the client conveyed in the access token with the respective data from the TLS handshake. > > > The AS can bind the lifetime of the refresh tokens to the session lifetime, > > i.e. automatically revoke it on logout. > > Yea, I saw your other email asking about refresh token revocation relating to > session management. Obviously for certain clients, this won't make sense, but > for implicit/browser-based ones it's a nice feature to have. > > The alternative, as you mentioned, is to not issue refresh tokens and do > token renewal the "same old way" via iframe with prompt=none, while still > using code flow. yes. Have you ever experienced issues with the latter approach and the browser’s 3rd party cookie policy? > > > The only potential „baby step“ I would see is to move towards „token > > id_token“. Since this requires signature/at_hash checks etc. I doubt this > > is really easier than moving to code and exchange the code for an access > > token. What’s your opinion? > > Even since OIDC arrived, this is the only flow I use for JS/browser-based > clients (anything less has always seemed so obviously inferior). So for me > and my customers, all browser-based clients I am involved in are already > there. Perhaps this is the reason for all of my questions/comments about the > recent BCP doc. Given "id_token token", CSP, and using the browser history > API to wipe the access token from browser history, we already have a decent > set of tools to mitigate attacks. As I already conceded, the only remaining > issue (IMO) is the short window of time the access token is in the URL. There are two angles to approach access token leakage and replay from two angles, (a) preventing leakage (that’s what you can do with the browser history API, TLS, ...) or (b) detecting replay (that’s what one can do with sender constraint access tokens). The focus of OAuth/OIDC was on (a) but experiences have shown this is of limited effectivity, especially in dynamic/open scenarios, which we are seeing increasingly due to open banking, eHealth, eID, …. So sealing the problem from both ends seems reasonable. > > Given that it seems to me that OIDC and OAuth2 are typically used together > (at least when a user is involved with authentication), I always wonder why > the OAuth and OIDC WGs are separate. Given that so much effort of the two > sets of specs overlap, it seems odd to keep adding onto the OAuth specs and > ignoring the added features that OIDC provides. I don't mean to derail this > thread, or step on any political toes, so apologies in advance. No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be aligned on that point. Thanks for the insights you shared. We will be publishing another revision of the OAuth Security BCP soon, which also adds recommendation and justification based on our discussions. kind regards, Torsten. > > > -Brock > smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
