Re: [OAUTH-WG] questions around OAuth 2.0 for Browser-Based Apps
Best practices according to whom? This list, and documents such as: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics Wouldn't the concerns of section 6 of your draft better be parts of a follow-up or addendum to rfc-6749? OAuth 2.1 has no normative changes over OAuth 2.0, and includes all the docs and learnings that have come out since OAuth 2.0 was published. Creating a new version allows implementors to reference OAuth 2.1 and deployments will know that it is compliant with all the learnings rather than having to reference numerous, sometimes conflicting documents. A good example is PKCE -- it is best practice and deals with the security concerns -- but trying to understand what to do reading both 6749 and 7636 is non-trivial for many. While adding an addendum would solve a few of the issues addressed by the 2.1 doc -- the WG decided that the 2.1 doc was the approach to take. /Dick On Tue, Jun 14, 2022 at 12:12 AM Yannick Majoros wrote: > Hello Aaron and anyone in the group, > > Could you further comment on my last email? > > I'd have an additional question: in > https://datatracker.ietf.org/doc/html/rfc6749#section-10 there is a list > of security considerations. Wouldn't the concerns of section 6 of your > draft better be parts of a follow-up or addendum to rfc-6749? > > Thanks, > > Yannick > > > Le sam. 11 juin 2022 à 20:55, Yannick Majoros a > écrit : > >> >> There is a lot of debate around the question. Are these really >> security best practices? >> >The intent of this draft is to document the best practices today. If >> >anything in the document is not the best way to do something given the >> >documented constraints, then that should be revisited. >> >> Best practices according to whom? There are various opinions on the >> subject, it's not black and white, so wouldn't it be best to be factual, >> e.g. describing attack X and counter-measures, and how solution Y is the >> best known tradeoff for that case. >> >> I indeed suggest section 6 to be revisited, as this the options described >> there are neither universally agreed upon, neither the best/only options to >> secure an application. >> >> I'd be happy to contribute, btw. I'm in the process of completing a kind >> of matrix which associates all known options (BFF, local/session >> storage/service worker/web worker/closure/token in a cookie/...), the >> security issues involved and their impact. I do also have POCs and further >> documentation for each solution, along with attack descriptions and their >> mitigations. >> >> > Did you consider using a service worker or other frontend solutions >> (web worker, closure...) for safe token storage? That would make a pure >> frontend solution at least as safe as cookies. >> >> This has been on my list to write up as another option. >> >> Great. I'd be interested in providing input here. Would it be useful? >> >> >> What if the backend is stateless and so doesn't have any session >> >You would need to use an encrypted session cookie to avoid storing >> >server-side state, but this is available in many web frameworks. >> >> Isn't that encrypted session cookie a kind of token? :-) Is this a best >> practice? >> >> Best regards, >> >> Yannick >> >> Le ven. 10 juin 2022 à 23:02, Aaron Parecki a écrit : >> >>> Hi Yannick, answers inline: >>> >>> > There is a lot of debate around the question. Are these really >>> security best practices? >>> >>> The intent of this draft is to document the best practices today. If >>> anything in the document is not the best way to do something given the >>> documented constraints, then that should be revisited. >>> >>> > Did you consider using a service worker or other frontend solutions >>> (web worker, closure...) for safe token storage? That would make a pure >>> frontend solution at least as safe as cookies. >>> >>> This has been on my list to write up as another option. >>> >>> > Why would a cookie be safer, as this opens CSRF attacks that would >>> make the same actions available to a hacker that would be possible by >>> getting hold of a token (which might even be more difficult)? >>> >>> The assumption is that you would also protect against CSRF attacks >>> like any typical web application. >>> >>> > What if the backend is stateless and so doesn't have any session >>> >>> You would need to use an encrypted session cookie to avoid storing >>> server-side state, but this is available in many web frameworks. >>> >>> Aaron >>> >>> >>> On Fri, Jun 10, 2022 at 5:12 AM Yannick Majoros >>> wrote: >>> > >>> > Hello, >>> > >>> > Regarding "OAuth 2.0 for Browser-Based Apps" section 6 ( >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09#section-6 >>> ), I do have some questions and concerns. Can I get in touch with someone >>> about this? >>> > >>> > My main questions are: >>> > - There is a lot of debate around the question. Are these really >>> security best practices? >>> > - Did you consider using a
Re: [OAUTH-WG] Multi-Subject JWT draft
Yes to both questions. On Tue, Jun 14, 2022 at 2:22 PM Warren Parad wrote: > Is it helpful to challenge this implementation? (and is this email thread > the right place to do it?) > > On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> It is a Nested JWT with at least *two related subjects*, one in the >> enclosed JWT and another in the enclosing JWT. >> Having said that, I do not have a strong opinion on the name and we could >> potentially change it to a name that more accurately reflects the scope of >> the document, if needed. >> >> The justification for this is that in a number of use cases there is a >> need for both JWTs to be present, to allow the resource server to apply >> authorization based on who requested the access to the resource and on >> behalf of who is the request. For example, a parent ordering medication for >> their child. There are other use cases described in the document. >> >> Regards, >> Rifaat >> >> >> >> >> On Tue, Jun 14, 2022 at 11:09 AM Warren Parad wrote: >> >>> After reading the draft I also have some concerns. This still isn't >>> multi-subject, right? As there is only one subject, there just happens to >>> be a new claim with additional information in it. I'm still behind on the >>> justification for creating this, as at first glance, either the user got an >>> access token on behalf of the other user to access their resources or they >>> are impersonating the other user. So I'm not totally sure I understand the >>> immediate value/problem statement, but that could be discussed separately. >>> >>> There's still only one subject, right? I would recommend that >>> `multi-subject` be removed from the draft name. For instance, why not: >>> >>>- Nested Subject JWT Claims >>> >>> Or maybe we want to talk about the value: >>> >>>- Delegating Authorization using Nested Subject Claims in JWTs >>> >>> >>> >>> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> Hi Dick, The initial scope of the document was very limited to extending the existing Nested JWT to allow the enclosing JWT to have its own claims. Since then, it was clear that there are many use cases that need such a mechanism that requires more than just a simple nesting of JWTs. That's the reason I changed the name, to reflect the larger scope of this document. I do not mind changing the name, if it makes sense. Would changing the name to Multi-Subject Nested JWT help address your concern? Regards, Rifaat On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt wrote: > Hi Rifaat > > I'm suspecting there was a conversation on changing the name to > multi-subject JWT. Would you provide a pointer or short summary? > > I find the name concerning as I am looking at a very different concept > that would also be considered a multi-subject JWT. > > > My use case is where user accounts have been merged, and the issuer > has multiple "sub" claims for the same user and would like to include all > the values in the JWT to signal to the RP that the accounts have been > merged. > > I was considering calling it "aka" and it would be an array of > identifiers. "aka" => Also Known As > > /Dick > > On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> I have just submitted an updated version of the *Multi-Subject JWT* >> draft (formerly known as Nested JWT) with more details. >> I would appreciate any reviews and feedback on this version. >> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt >> >> Regards, >> Rifaat >> >> ___ >> 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] Multi-Subject JWT draft
Is it helpful to challenge this implementation? (and is this email thread the right place to do it?) On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef wrote: > It is a Nested JWT with at least *two related subjects*, one in the > enclosed JWT and another in the enclosing JWT. > Having said that, I do not have a strong opinion on the name and we could > potentially change it to a name that more accurately reflects the scope of > the document, if needed. > > The justification for this is that in a number of use cases there is a > need for both JWTs to be present, to allow the resource server to apply > authorization based on who requested the access to the resource and on > behalf of who is the request. For example, a parent ordering medication for > their child. There are other use cases described in the document. > > Regards, > Rifaat > > > > > On Tue, Jun 14, 2022 at 11:09 AM Warren Parad wrote: > >> After reading the draft I also have some concerns. This still isn't >> multi-subject, right? As there is only one subject, there just happens to >> be a new claim with additional information in it. I'm still behind on the >> justification for creating this, as at first glance, either the user got an >> access token on behalf of the other user to access their resources or they >> are impersonating the other user. So I'm not totally sure I understand the >> immediate value/problem statement, but that could be discussed separately. >> >> There's still only one subject, right? I would recommend that >> `multi-subject` be removed from the draft name. For instance, why not: >> >>- Nested Subject JWT Claims >> >> Or maybe we want to talk about the value: >> >>- Delegating Authorization using Nested Subject Claims in JWTs >> >> >> >> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >>> Hi Dick, >>> >>> The initial scope of the document was very limited to extending the >>> existing Nested JWT to allow the enclosing JWT to have its own claims. >>> Since then, it was clear that there are many use cases that need such a >>> mechanism that requires more than just a simple nesting of JWTs. That's the >>> reason I changed the name, to reflect the larger scope of this document. >>> >>> I do not mind changing the name, if it makes sense. >>> Would changing the name to Multi-Subject Nested JWT help address your >>> concern? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt >>> wrote: >>> Hi Rifaat I'm suspecting there was a conversation on changing the name to multi-subject JWT. Would you provide a pointer or short summary? I find the name concerning as I am looking at a very different concept that would also be considered a multi-subject JWT. My use case is where user accounts have been merged, and the issuer has multiple "sub" claims for the same user and would like to include all the values in the JWT to signal to the RP that the accounts have been merged. I was considering calling it "aka" and it would be an array of identifiers. "aka" => Also Known As /Dick On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> wrote: > I have just submitted an updated version of the *Multi-Subject JWT* > draft (formerly known as Nested JWT) with more details. > I would appreciate any reviews and feedback on this version. > https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt > > Regards, > Rifaat > > ___ > 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] Multi-Subject JWT draft
It is a Nested JWT with at least *two related subjects*, one in the enclosed JWT and another in the enclosing JWT. Having said that, I do not have a strong opinion on the name and we could potentially change it to a name that more accurately reflects the scope of the document, if needed. The justification for this is that in a number of use cases there is a need for both JWTs to be present, to allow the resource server to apply authorization based on who requested the access to the resource and on behalf of who is the request. For example, a parent ordering medication for their child. There are other use cases described in the document. Regards, Rifaat On Tue, Jun 14, 2022 at 11:09 AM Warren Parad wrote: > After reading the draft I also have some concerns. This still isn't > multi-subject, right? As there is only one subject, there just happens to > be a new claim with additional information in it. I'm still behind on the > justification for creating this, as at first glance, either the user got an > access token on behalf of the other user to access their resources or they > are impersonating the other user. So I'm not totally sure I understand the > immediate value/problem statement, but that could be discussed separately. > > There's still only one subject, right? I would recommend that > `multi-subject` be removed from the draft name. For instance, why not: > >- Nested Subject JWT Claims > > Or maybe we want to talk about the value: > >- Delegating Authorization using Nested Subject Claims in JWTs > > > > On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> Hi Dick, >> >> The initial scope of the document was very limited to extending the >> existing Nested JWT to allow the enclosing JWT to have its own claims. >> Since then, it was clear that there are many use cases that need such a >> mechanism that requires more than just a simple nesting of JWTs. That's the >> reason I changed the name, to reflect the larger scope of this document. >> >> I do not mind changing the name, if it makes sense. >> Would changing the name to Multi-Subject Nested JWT help address your >> concern? >> >> Regards, >> Rifaat >> >> >> >> >> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt wrote: >> >>> Hi Rifaat >>> >>> I'm suspecting there was a conversation on changing the name to >>> multi-subject JWT. Would you provide a pointer or short summary? >>> >>> I find the name concerning as I am looking at a very different concept >>> that would also be considered a multi-subject JWT. >>> >>> >>> My use case is where user accounts have been merged, and the issuer has >>> multiple "sub" claims for the same user and would like to include all the >>> values in the JWT to signal to the RP that the accounts have been merged. >>> >>> I was considering calling it "aka" and it would be an array of >>> identifiers. "aka" => Also Known As >>> >>> /Dick >>> >>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> I have just submitted an updated version of the *Multi-Subject JWT* draft (formerly known as Nested JWT) with more details. I would appreciate any reviews and feedback on this version. https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Regards, Rifaat ___ 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] Multi-Subject JWT draft
After reading the draft I also have some concerns. This still isn't multi-subject, right? As there is only one subject, there just happens to be a new claim with additional information in it. I'm still behind on the justification for creating this, as at first glance, either the user got an access token on behalf of the other user to access their resources or they are impersonating the other user. So I'm not totally sure I understand the immediate value/problem statement, but that could be discussed separately. There's still only one subject, right? I would recommend that `multi-subject` be removed from the draft name. For instance, why not: - Nested Subject JWT Claims Or maybe we want to talk about the value: - Delegating Authorization using Nested Subject Claims in JWTs On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef wrote: > Hi Dick, > > The initial scope of the document was very limited to extending the > existing Nested JWT to allow the enclosing JWT to have its own claims. > Since then, it was clear that there are many use cases that need such a > mechanism that requires more than just a simple nesting of JWTs. That's the > reason I changed the name, to reflect the larger scope of this document. > > I do not mind changing the name, if it makes sense. > Would changing the name to Multi-Subject Nested JWT help address your > concern? > > Regards, > Rifaat > > > > > On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt wrote: > >> Hi Rifaat >> >> I'm suspecting there was a conversation on changing the name to >> multi-subject JWT. Would you provide a pointer or short summary? >> >> I find the name concerning as I am looking at a very different concept >> that would also be considered a multi-subject JWT. >> >> >> My use case is where user accounts have been merged, and the issuer has >> multiple "sub" claims for the same user and would like to include all the >> values in the JWT to signal to the RP that the accounts have been merged. >> >> I was considering calling it "aka" and it would be an array of >> identifiers. "aka" => Also Known As >> >> /Dick >> >> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >>> I have just submitted an updated version of the *Multi-Subject JWT* >>> draft (formerly known as Nested JWT) with more details. >>> I would appreciate any reviews and feedback on this version. >>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt >>> >>> Regards, >>> Rifaat >>> >>> ___ >>> 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] Multi-Subject JWT draft
Hi Dick, The initial scope of the document was very limited to extending the existing Nested JWT to allow the enclosing JWT to have its own claims. Since then, it was clear that there are many use cases that need such a mechanism that requires more than just a simple nesting of JWTs. That's the reason I changed the name, to reflect the larger scope of this document. I do not mind changing the name, if it makes sense. Would changing the name to Multi-Subject Nested JWT help address your concern? Regards, Rifaat On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt wrote: > Hi Rifaat > > I'm suspecting there was a conversation on changing the name to > multi-subject JWT. Would you provide a pointer or short summary? > > I find the name concerning as I am looking at a very different concept > that would also be considered a multi-subject JWT. > > > My use case is where user accounts have been merged, and the issuer has > multiple "sub" claims for the same user and would like to include all the > values in the JWT to signal to the RP that the accounts have been merged. > > I was considering calling it "aka" and it would be an array of > identifiers. "aka" => Also Known As > > /Dick > > On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> I have just submitted an updated version of the *Multi-Subject JWT* >> draft (formerly known as Nested JWT) with more details. >> I would appreciate any reviews and feedback on this version. >> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt >> >> Regards, >> Rifaat >> >> ___ >> 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] Multi-Subject JWT draft
Hi Rifaat I'm suspecting there was a conversation on changing the name to multi-subject JWT. Would you provide a pointer or short summary? I find the name concerning as I am looking at a very different concept that would also be considered a multi-subject JWT. My use case is where user accounts have been merged, and the issuer has multiple "sub" claims for the same user and would like to include all the values in the JWT to signal to the RP that the accounts have been merged. I was considering calling it "aka" and it would be an array of identifiers. "aka" => Also Known As /Dick On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef wrote: > I have just submitted an updated version of the *Multi-Subject JWT* draft > (formerly known as Nested JWT) with more details. > I would appreciate any reviews and feedback on this version. > https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt > > Regards, > Rifaat > > ___ > 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-WG] Multi-Subject JWT draft
I have just submitted an updated version of the *Multi-Subject JWT* draft (formerly known as Nested JWT) with more details. I would appreciate any reviews and feedback on this version. https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] questions around OAuth 2.0 for Browser-Based Apps
Hello Aaron and anyone in the group, Could you further comment on my last email? I'd have an additional question: in https://datatracker.ietf.org/doc/html/rfc6749#section-10 there is a list of security considerations. Wouldn't the concerns of section 6 of your draft better be parts of a follow-up or addendum to rfc-6749? Thanks, Yannick Le sam. 11 juin 2022 à 20:55, Yannick Majoros a écrit : > >> There is a lot of debate around the question. Are these really security > best practices? > >The intent of this draft is to document the best practices today. If > >anything in the document is not the best way to do something given the > >documented constraints, then that should be revisited. > > Best practices according to whom? There are various opinions on the > subject, it's not black and white, so wouldn't it be best to be factual, > e.g. describing attack X and counter-measures, and how solution Y is the > best known tradeoff for that case. > > I indeed suggest section 6 to be revisited, as this the options described > there are neither universally agreed upon, neither the best/only options to > secure an application. > > I'd be happy to contribute, btw. I'm in the process of completing a kind > of matrix which associates all known options (BFF, local/session > storage/service worker/web worker/closure/token in a cookie/...), the > security issues involved and their impact. I do also have POCs and further > documentation for each solution, along with attack descriptions and their > mitigations. > > > Did you consider using a service worker or other frontend solutions (web > worker, closure...) for safe token storage? That would make a pure frontend > solution at least as safe as cookies. > > This has been on my list to write up as another option. > > Great. I'd be interested in providing input here. Would it be useful? > > >> What if the backend is stateless and so doesn't have any session > >You would need to use an encrypted session cookie to avoid storing > >server-side state, but this is available in many web frameworks. > > Isn't that encrypted session cookie a kind of token? :-) Is this a best > practice? > > Best regards, > > Yannick > > Le ven. 10 juin 2022 à 23:02, Aaron Parecki a écrit : > >> Hi Yannick, answers inline: >> >> > There is a lot of debate around the question. Are these really security >> best practices? >> >> The intent of this draft is to document the best practices today. If >> anything in the document is not the best way to do something given the >> documented constraints, then that should be revisited. >> >> > Did you consider using a service worker or other frontend solutions >> (web worker, closure...) for safe token storage? That would make a pure >> frontend solution at least as safe as cookies. >> >> This has been on my list to write up as another option. >> >> > Why would a cookie be safer, as this opens CSRF attacks that would make >> the same actions available to a hacker that would be possible by getting >> hold of a token (which might even be more difficult)? >> >> The assumption is that you would also protect against CSRF attacks >> like any typical web application. >> >> > What if the backend is stateless and so doesn't have any session >> >> You would need to use an encrypted session cookie to avoid storing >> server-side state, but this is available in many web frameworks. >> >> Aaron >> >> >> On Fri, Jun 10, 2022 at 5:12 AM Yannick Majoros >> wrote: >> > >> > Hello, >> > >> > Regarding "OAuth 2.0 for Browser-Based Apps" section 6 ( >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09#section-6 >> ), I do have some questions and concerns. Can I get in touch with someone >> about this? >> > >> > My main questions are: >> > - There is a lot of debate around the question. Are these really >> security best practices? >> > - Did you consider using a service worker or other frontend solutions >> (web worker, closure...) for safe token storage? That would make a pure >> frontend solution at least as safe as cookies. >> > - Why would a cookie be safer, as this opens CSRF attacks that would >> make the same actions available to a hacker that would be possible by >> getting hold of a token (which might even be more difficult)? >> > - What if the backend is stateless and so doesn't have any session >> (which defeats 6.1 & 6.2 and leaves no option according to current draf)? >> > >> > Best regards. >> > >> > Yannick Majoros >> > Valuya sprl >> > ___ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Yannick Majoros > Valuya sprl > > -- Yannick Majoros Valuya sprl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
