Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Vineet Banga <[e-mail]>]

> > >> On 16. Nov 2019, at 02:07, Vineet Banga <vineetbanga=
[e-mail]> wrote:
> > >>
> > >> Just one comment/question at the moment:
> > > >3.1.1 - Is there any recommendation around leveraging state vs using
multiple URIs (with exact match) to remember the application state of the
client? I have seen exploding list of registered redirect URIs, but am not
aware of any security issues around this usage. But would like to check if
there are any opinions on this matter..
> >
> > >The BCP recommends transaction specific one time use state values for
CSRF prevention. To achieve the same protection level with redirect URI’s
and exact match, one would need to register per transaction redirect URI
values.
> >
> > >Do your redirect URIs meet those requirements?
> > No. I think the options are using state for purely csrf or using
[I-D.bradley-oauth-jwt-encoded-state], which is called our in the BCP.
Using encoded jwt can be used to limit the number of redirect uris.

> So you are saying "state" is used for CSRF. Then what is the rational of
your original question? To move towards application state encoded in
redirect URIs?

Let me restate my original question. I agree with the usage of state for
CSRF protection, but it can also be used to capture the application state
(as specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if
there is any recommendation between using state for both csrf and
application state Vs. relying completely on redirect URIs to
maintain application state.

As an OAuth provider, I lean towards avoiding long and dynamic list of
redirect URIs. But I do understand that using state for both CSRF
protection and application state adds burden on clients/app developers.

Vineet


On Tue, Nov 19, 2019 at 10:25 AM Torsten Lodderstedt <
[e-mail]> wrote:

>
>
> > On 17. Nov 2019, at 05:42, Vineet Banga <[e-mail]> wrote:
> >
> >
> > On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt <
> [e-mail]> wrote:
> >
> > >> On 16. Nov 2019, at 02:07, Vineet Banga <vineetbanga=
> [e-mail]> wrote:
> > >>
> > >> Just one comment/question at the moment:
> > > >3.1.1 - Is there any recommendation around leveraging state vs using
> multiple URIs (with exact match) to remember the application state of the
> client? I have seen exploding list of registered redirect URIs, but am not
> aware of any security issues around this usage. But would like to check if
> there are any opinions on this matter..
> >
> > >The BCP recommends transaction specific one time use state values for
> CSRF prevention. To achieve the same protection level with redirect URI’s
> and exact match, one would need to register per transaction redirect URI
> values.
> >
> > >Do your redirect URIs meet those requirements?
> > No. I think the options are using state for purely csrf or using
> [I-D.bradley-oauth-jwt-encoded-state], which is called our in the BCP.
> Using encoded jwt can be used to limit the number of redirect uris.
>
> So you are saying "state" is used for CSRF. Then what is the rational of
> your original question? To move towards application state encoded in
> redirect URIs?
>
> >
> >
> >
> >
> >
> > >
> > >
> > > On Wed, Nov 6, 2019 at 12:27 AM Hannes Tschofenig <
> [e-mail]> wrote:
> > > Hi all,
> > >
> > > this is a working group last call for "OAuth 2.0 Security Best Current
> Practice".
> > >
> > > Here is the document:
> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
> > >
> > > Please send you comments to the OAuth mailing list by Nov. 27, 2019.
> > > (We use a three week WGLC because of the IETF meeting.)
> > >
> > > Ciao
> > > Hannes & Rifaat
> > >
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>