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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Nov 2019 08:26:49 +0000

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.

---

From: Jared Jennings <[email-masked]>
Date: Wed, 6 Nov 2019 14:16:19 -0600

Hi,

This is my first time reviewing a document or responding to the group. So,
with that introduction feel free to guide me along the way.

Reading through the document, I had a few high-level questions first. I
will have more detailed comments later, once I know I'm on the right track
and I assume those comments I should just share with the mailing list?

1. Since the document is a "Best Practices" document, are the words "MUST"
and "REQUIRED" and other definitive terms? Would instead SHOULD and
RECOMMENDED be used?

2. Should other possible threats and vulnerabilities be included? Meaning,
is the list the definitive known list?

Thanks!
-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152

On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig <[email-masked]>
wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Nov 2019 15:55:54 -0500

1. Normative MUST/REQUIRED is fine in a BCP. 

2. This is not the definitive list, but instead the best list of things that we have at this time. There will be more attacks, and more mitigations for those attacks.

 — Justin

> On Nov 6, 2019, at 3:16 PM, Jared Jennings <[email-masked]> wrote:
> 
> Hi,
> 
> This is my first time reviewing a document or responding to the group. So, with that introduction feel free to guide me along the way.
> 
> Reading through the document, I had a few high-level questions first. I will have more detailed comments later, once I know I'm on the right track and I assume those comments I should just share with the mailing list?
> 
> 1. Since the document is a "Best Practices" document, are the words "MUST" and "REQUIRED" and other definitive terms? Would instead SHOULD and RECOMMENDED be used?
> 
> 2. Should other possible threats and vulnerabilities be included? Meaning, is the list the definitive known list?
> 
> Thanks!
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Denis <[email-masked]>
Date: Thu, 7 Nov 2019 09:16:29 +0100

Hello Jared,

You raised the following question :
*
**Should other possible threats and vulnerabilities be included? 
Meaning, is the list the definitive known list?*

This list is certainly not a "definitive /known /list" since there 
exists an additional /known /threat that has been advertised to this list
for the fist time *exactly* 3 years ago. It is the right time to blow 
three candles !

This is not either "the best list of things that we have at this time", 
as Justin mentioned.

The current document only addresses external "attackers". The case of 
collusion between users is not mentioned.

The first description of such a kind of attack, named the "*Alice and 
Bob Collusion*" attack, was mentioned on this list
*on November the 7 th, 2016*. It is available at: 
https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

Considering collaborative users is critical when considering age 
verification. If a user legitimately obtains one attribute demonstrating
that he is over 18 and if that user voluntarily transmits such an 
attribute to another user that is below 18, the RP should be in a position
to detect that the attribute does not belong to that other user and 
should thus be in a position to reject it.

It is often believed that protecting secret keys or private keys in a 
secure element is an efficient and sufficient way to prevent such a 
collusion
attack between users against a RP. However, this is not true. There have 
been some implementations using OAuth and smart cards, but the simple 
addition
of these two elements does not necessarily provide a secure solution.

The first user is in a position to perform all the cryptographic 
computations that the other user needs since it can perform any 
cryptographic computation
that the other user needs using secret or private key stored in his 
secure element.

*Whatever kind of cryptographic is being used, when two users 
collaborate, a software-only solution will be unable to prevent the 
transmission *
*       of an attribute of a user that possess it to another user that 
does not possess it. *
**
Additional functional properties are required for the secure element and 
the presence of those properties needs to be verified both by the RP
and the Authorization Server. There are six roles to be considered in 
order to be able to counter the Alice and Bob Collusion attack, namely:

  * Users (usually human users),
  * Clients,
  * Secure Elements (SE),
  * Authorization Servers (AS),
  * Relying Parties (RP), and
  * Secure Element Providers (SEP).

Note: Since RFC 6819 (OAuth 2.0 Threat Model and Security 
Considerations*) *does not include any figure, a figure illustrating 
these roles would be really helpful for the readers.

As a consequence, the protocols SHALL support exchanges where 
computations performed by the secure elements are part of the protocols.

I understand that it may be embarrassing to describe in this document an 
attack that cannot be countered using any of the OAuth 2.0 Security Best 
Current Practices
... but this is not a reason to conceal user's collaborative attacks in 
this document.

The fact is that any (secure) solution to the ABC attack SHALL be based 
on the use of secure elements and hence CANNOT be based on the use of a 
software only solution,
whatever kind of cryptographic algorithms would be used.

I believe that some of the material provided both in this email and in 
the email from November the 7 th, 2016 should be incorporated into this 
document
in order to address this missing threat.

Denis

> 2. This is not the definitive list, but instead the best list of 
> things that we have at this time. There will be more attacks, and more 
> mitigations for those attacks.
>
>  — Justin
>
>> On Nov 6, 2019, at 3:16 PM, Jared Jennings <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> This is my first time reviewing a document or responding to the 
>> group. So, with that introduction feel free to guide me along the way.
>>
>> Reading through the document, I had a few high-level questions first. 
>> I will have more detailed comments later, once I know I'm on the 
>> right track and I assume those comments I should just share with the 
>> mailing list?
>>
>> 1. Since the document is a "Best Practices" document, are the words 
>> "MUST" and "REQUIRED" and other definitive terms? Would instead 
>> SHOULD and RECOMMENDED be used?
>>
>> 2. Should other possible threats and vulnerabilities be included? 
>> Meaning, is the list the definitive known list?
>>
>> Thanks!
>> -Jared
>> Skype:jaredljennings
>> Signal:+1 816.730.9540
>> On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi all,
>>
>>     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.
>>

---

From: Daniel Fett <[email-masked]>
Date: Thu, 7 Nov 2019 14:24:54 +0100

Hi Denis,

> *       of an attribute of a user that possess it to another user that
To stay in OAuth lingo, what you are saying is: Two collaborating
clients can exchange their access tokens and use them.

Is that a correct summary of your attack?

-Daniel

---

From: Denis <[email-masked]>
Date: Fri, 8 Nov 2019 08:38:07 +0100

Daniel,

No. It is not a correct summary. One client can allow another client to 
get an access token that belongs to it.
The key point is that a software only solution can't prevent this 
collaborative attack and since, at this time,
the OAuth WG is not considering the use of secure elements, the attack 
cannot be countered.

Please have a look at: 

Denis

>> *       of an attribute of a user that possess it to another user 
>> that does not possess it. *
>>

---

From: Hans Zandbelt <[email-masked]>
Date: Fri, 8 Nov 2019 08:34:13 +0000

one client can always share the protected data with another client once
retrieved, regardless of pop or secure elements

Hans.

On Fri, Nov 8, 2019 at 8:38 AM Denis <[email-masked]> wrote:

> To stay in OAuth lingo, what you are saying is: Two collaborating clients
> can exchange their access tokens and use them.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Daniel Roesler <[email-masked]>
Date: Fri, 8 Nov 2019 06:49:40 -0600

Howdy,

In the "3.1 Protecting Redirect-Based Flows" > "3.1.1. Authorization
Code Grant" section, is there guidance on when it is appropriate (if
ever) to automatically generate a new authorization code and redirect
back to the client?

A recent exploit[1] on Github's OAuth implementation was practical
because if you make an authorization request and the resource owner is
already authenticated and the scope is already authorized, Github will
silently generate a new authorization code and redirect the user back
to the redirect_uri without asking them to click "Authorize" again.

How the exploit worked:

1. The client makes an ajax HEAD request to the OAuth authorization
endpoint, which will silently create the authorization grant (this was
the security exploit that was patched).

2. However, since the ajax response was blocked via CORS, the client
couldn't receive the authorization code in the response parameters.

3. So, the client then redirected the user to Github's authorization
endpoint with the same authorization code request (only this time as a
real GET redirect).

4. Github instantly redirected the user back to the client's
redirect_uri with a new authorization code and without asking for any
user interaction.

It seems strange to me that OAuth should allow for transparent
authorization code redirects without resource owner confirmation. This
situation only comes up when something weird is happening, such as
when a client loses their valid access|refresh_token, but isn't that
all the more reason to clarify that you should always ask for resource
owner confirmation of the scope, even in scenarios where you are just
re-authorizing the same scope as before?

Had Github asked for confirmation on step 4 above, the practicality of
the HEAD exploit would have been reduced because the user would have
been presented with an unexpected Allow/Deny Github OAuth dialogue,
possibly alerting them to the fact that something strange was going
on.

Anyway, I'm trying to find guidance on transparent redirects for
authorization code grants. There's a whole host of both security and
application logic issues that could come up from such behavior, so I'd
like to ask for clarification in best practices.

[1]: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html

Daniel Roesler
Co-founder & CTO, UtilityAPI
[email-masked]

---

From: Denis <[email-masked]>
Date: Fri, 8 Nov 2019 14:13:45 +0100

Hello Hans,

You wrote:

> one client can always share the protected data with another client 
> once retrieved, regardless of pop or secure elements

No, there exist means that prevent a client to share the protected data 
with another client , simply because the client cannot access to it.
The protected data is placed inside the secure element and thus a client 
has no way to extract it for the benefit of another client.

The protected data is used by the secure element in such a way so that 
it cannot be used for the benefit of another user.

But we are already in the field of the solutions and no more in the 
field of the requirements.

Denis

>
> Hans.
>
> On Fri, Nov 8, 2019 at 8:38 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Daniel,
>
>     No. It is not a correct summary. One client can allow another
>     client to get an access token that belongs to it.
>     the OAuth WG is not considering the use of secure elements, the
>     attack cannot be countered.
>
>     Please have a look at:
>>>     collaborate, a software-only solution will be unable to prevent
>>>     the transmission *
>>>     *of an attribute of a user that possess it to another user that
>>>     does not possess it. *
>>>
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>

---

From: Hans Zandbelt <[email-masked]>
Date: Fri, 8 Nov 2019 14:37:18 +0100

screenshot...

Hans.

On Fri, Nov 8, 2019 at 2:13 PM Denis <[email-masked]> wrote:

> The protected data is used by the secure element in such a way so that it
> cannot be used for the benefit of another user.
>
> But we are already in the field of the solutions and no more in the field
> of the requirements.
>
> Denis
>
>
> Hans.
>

---

From: Daniel Fett <[email-masked]>
Date: Fri, 8 Nov 2019 15:30:02 +0100

I have the feeling that this attack aims at breaking a security property
that OAuth does not claim to fulfill (and that nobody expects OAuth to
fulfill):

"Given two colluding clients A and B, where A has obtained an access
token T, B cannot use T to access protected resources."
(analogously for two users U_A and U_B of the clients, where the users
have some session with a backend client.)

And there are good reasons why this is not captured by the security
property (Hans' screenshot, for example).

As far as I know, this property is neither achieved by classical
first-party session-based authentication/authorization nor by any other
web-based mechanism, or is it?

-Daniel

Am 08.11.19 um 14:13 schrieb Denis:
> No, there exist means that prevent a client to share the protected
> data with another client , simply because the client cannot access to it.
> The protected data is placed inside the secure element and thus a
> client has no way to extract it for the benefit of another client.
>
>>>>            *Whatever kind of cryptographic is being used, when two
>>>>     users collaborate, a software-only solution will be unable to
>>>>     prevent the transmission *
>>>>     *       of an attribute of a user that possess it to another
>>>>     user that does not possess it. *
>>>>
>>>     To stay in OAuth lingo, what you are saying is: Two
>>>     collaborating clients can exchange their access tokens and use them.
>>>

---

From: David Waite <[email-masked]>
Date: Fri, 8 Nov 2019 13:01:25 -0700

Hello Daniel!

> like to ask for clarification in best practices.

OAuth does not provide a way to recover from an expired access token barring a refresh token, which also can be invalidated. In particular, the only front channel ‘continuation’ parameter I know of is ‘id_token_hint’ in OIDC.

There are deployments today (admittedly mostly using implicit flow) which do not have refresh tokens. A mandate that you SHOULD ask for re-consent would be a recommendation that they have to interrupt the user periodically to continue access - which would just create another security vs usability decision.

Per your point above, the actual security issue was that GitHub 1) had the authorization endpoint serve double-duty and 2) treated HEAD requests as a quasi GET/POST to create a grant in their database to the client without user confirmation. The solution for this is not to ask the user to re-confirm on every request..

That said, it does make sense for some deployments to periodically invalidate a refresh token, even for the purpose of bringing the user back to re-consent permissions (aka self-audit). An application could theoretically distinguish from tokens granted by the protected user needing to be invalidated to drive the user to re-consent, and operationally granted tokens which are assumed to be actively managed and not tied to any user account.

-DW

> On Nov 8, 2019, at 5:49 AM, Daniel Roesler <daniel=[email-masked]> wrote:
> 
> Howdy,
>

---

From: Daniel Roesler <[email-masked]>
Date: Sat, 9 Nov 2019 11:43:34 -0600

Howdy DW,

Thanks very much for your response! It's totally understandable that
the authorization server should ask for re-confirm if the
refresh_token is no longer valid, and it's also understandable that if
you're using implicit flow with only an access_token that you don't
need to ask for re-confirm every time.

However, I'm specifically interested in authorization code flow
situations where an authorization request is made despite the client
already having a valid grant. It's an atypical request for the client
to make, since they theoretically should already have valid
access/refresh_tokens, but when it does happen, what is the
authorization server supposed to do? Is it bad for them to
auto-redirect back with another authorization code without asking the
user to confirm again? Shouldn't they treat the authorization request
the same way they treat all other authorization requests (by asking
for user confirmation)?

It seems there are situations where this transparent redirect behavior
can be dangerous[1][2] or misleading[3].

[1]: Issuing a new authorization code without requiring confirmation
from the user is what allowed Github's HEAD exploit to be practical
because it allowed the client to exfiltrate the authorization code
without user interaction. Had Github always requested user to click
Allow, even though the user would have already granted access through
the HEAD exploit, the client wouldn't be able to obtain the
authorization code without user interaction. I understand that fixing
the HEAD exploit in the first place is the first and best solution,
but the lack of user interaction is what elevated this exploit from
high to critical.

[2]: For users that have multiple accounts with a client (e.g.
personal, anonymous, work, etc.), if an authorization server
auto-redirects for repeated authorization requests, once that user
connects one account via OAuth to the client, the client can then
attempt authorization requests for other accounts and see which ones
get auto-redirect back. This can, without user interaction,
potentially de-anonymize or map different accounts on the client to
the same user that the user didn't necessarily want to be mapped.

[3]: Privacy regulations are adding more and more for users to
"opt-in" to various types of data access or data sharing, and
sometimes consent requirements for the client don't line up with the
expiration/revocation timelines of the authorization server (e.g.
clients may be required to get an opt-in annually, even if the
authorization server grant never expires). Clients are assuming that
using the redirect back with an authorization code is proof of consent
for their privacy compliance records (it is called Open Authorization,
after all). However, with transparent redirects in the authorization
code flow, this isn't necessarily true and you can no longer rely on
OAuth as a valid mechanism for proving user consent.

I realize that it's open to the authorization server to issue
authorization codes how they see fit. It just strikes me as odd that
there's not a lot of guidance around when transparent redirects are
safe, when user interaction should occur, and the risks and
implications of both behaviors.

Daniel Roesler

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 9 Nov 2019 21:08:25 +0100

Hi Daniel,

> Am 09.11.2019 um 18:44 schrieb Daniel Roesler <daniel=[email-masked]>:
> 

User consent is more difficult than it looks on first sight. That’s the reason why it is hard to come up with general guidance.

To start with, user consent is not a security measure per se. It is a measure to establish the legal basis for access to services and data on behalf of the resource owner. It is important to gather the consent but also to enforce this consent (typically by the RS) and ensure that only the legit client is able to use the tokens issued based on a certain consent (scope). That’s were various security pieces come into play.

If AS and client belong to the same legal entity, there is typically no need to gather consent since the user already consented to the terms and privacy policy of the respective service provider. So automatic code issuance is fine as long as the user is sufficiently authenticated (policy determine by RS).

If AS and client belong to different legal entities, the AS can ask every time - that’s on the super safe side but inconvenient. That’s why ASs may store the consent and avoid another dialog, if the same client asks again for the same scope.

But what does „same client“ mean? Is it the client_id? Sounds reasonable for a web app, but would also mean instances of the same native app residing on different devices could share the consent. That’s great from a convenience perspective but the AS has to really make sure it’s the same user on the other device using the 3rd party app and it’s the same app again otherwise an attacker could easily abuse the grant.

This in turn would call for client authentication, which in this case (same client_id shared among instances) means the OAuth dialog must happen in a backend otherwise the secret could be obtained by an attacker from the installed app.

I hear “dynamic client registration” to give every instance client_id and secret? Well, looks like an alternative, but one needs to establish the relationship to the legal entity in a secure manner, otherwise sharing the consent is dangerous. Software statements or registration access tokens are the means at hand but both are shared secrets one would need to deploy with all app instances ... not advisable at all.

Let’s talk about “same scope”: equality can be defined as byte level string equality or by interpreting the scope. The first approach will cause another user consent dialog if the order of the scope values change (or just a space is added). The latter approach is highly implementation specific since left undefined in RFC 6749.

In the case of Open Banking and similar scenarios, this scope will be fine grained, dynamic or even transactional meaning storing a consent and issuing another code in subsequent authorization transactions might be possible but scope value specific.

Constraints regarding the duration of a consent can easily be enforced by the AS. It just won’t issue further codes or access tokens (in case of refresh token grant) if the consent needs to be refreshed.

bottom line: to define when an AS can issue an authorization code without asking for user consent again is easy. Implementing a policy that is secure and convenient is not.

We are working on more sophisticated ways to represent and compare scopes (https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03). The client identification problem will most likely stay.

kind regards,
Torsten.

---

From: David Waite <[email-masked]>
Date: Sat, 9 Nov 2019 14:23:15 -0700

> This in turn would call for client authentication, which in this case (same client_id shared among instances) means the OAuth dialog must happen in a backend otherwise the secret could be obtained…

<pipes back in>

Very true, and this is one reason why in Native Apps and Web Apps deployments (which use public clients) the AS may use the ability to redirect to a unique redirect URI as a form of lightweight identifier/ownership proof. That means some forms of redirect URI where you cannot provide unique ownership (custom schemes on most platforms, localhost redirects) should understand that other software can imitate the given client to the user, and that as a result allowed authorizations might be reduced and SSO/consent should be more carefully managed.

> I hear “dynamic client registration” to give every instance client_id and secret? Well, looks like an alternative, but one needs to establish the relationship to the legal entity in a secure manner…

As DCR gives you the means to uniquely identify a client, I would expect each instance to be represented as a separate client. That brings you up from ‘consent on every token request by every client instance’ to ‘consent once for each client instance’. You could still use something like unique redirect URI or platform attestation to make it 'consent once per client’.

DCR does give you another handle for tracking a client instance across authorization requests, which can be otherwise difficult in the scenario public clients relying on a browser user agent. A native app may be able to persist that better than say what you get via browser storage.

> We are working on more sophisticated ways to represent and compare scopes (https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03 <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03>). The client identification problem will most likely stay.

One of the benefits of the OAuth abstraction is that it puts the authorization business logic (including things like presentation) squarely in the hands of the AS. OAuth gives the flexibility for the AS to implement that logic appropriately, as well as to evolve that logic without impacting the protocol contract with the clients/protected resources.

That there even is consent is part of that business requirements on an organization, so it would be difficult to give formal recommendations outside of business needs (e.g. regulatory compliance). Outside that, recommendations would be non-prescriptive considerations for AS implementors, such as “limit the scopes available to a client based on client need, client audit, business relationship, and regulatory restrictions/requirements”

There are also cases where general user interaction (e.g. non-transparent SSO/authorization) is technically desirable, such as fortifying the AS from being classified as a tracker in Safari ITP or ensuring Universal Links will work on iOS.  If you are requiring the user click to continue as a technical solution, you might decide to use that as an opportunity for information or informed consent as well.

-DW

---

From: Denis <[email-masked]>
Date: Tue, 12 Nov 2019 10:19:22 +0100

Daniel,

> I have the feeling that this attack aims at breaking a security 
> property that OAuth does not claim to fulfill (and that nobody expects 
> OAuth to fulfill):

The first comment sent to the list was to ask whether the list of 
attacks was complete. IMO, the list should not be limited to the attacks 
that can be mitigated
using best current practices, but should include all /known /kinds of 
attacks.

At the moment a reader might get the impression that all /known /types 
of attacks have been analyzed and considered.

The document even refers to formal methods (which might impress some 
readers), but when looking at the perimeter of the model that has been 
used,
it is obvious that the ABC attack could not be discovered and thus 
considered.

> property (Hans' screenshot, for example).
???
> first-party session-based authentication/authorization nor by any 
> other web-based mechanism, or is it?

Please refer back to what I said, i.e."Whatever kind of cryptographic is 
being used, when two users collaborate, a software-only solution will be 
unable to prevent
the transmission of an attribute of a user that possess it to another 
user that does not possess it"and you will get the response. Since OAuth 
is a software based solution,
it is unable to counter clients collusion attacks. Adding a secure 
element to only protect private/secret keys is ineffective to counter 
clients collusion attacks.

For potential implementers, it is important to know the limitations of a 
protocol before implementing it.

Denis

>> The protected data is used by the secure element in such a way so 
>> that it cannot be used for the benefit of another user.
>>
>>>     The key point is that a software only solution can't prevent
>>>     this collaborative attack and since, at this time,
>>>>>     collaborate, a software-only solution will be unable to
>>>>>     *of an attribute of a user that possess it to another user

---

From: Vineet Banga <[email-masked]>
Date: Fri, 15 Nov 2019 17:07:52 -0800

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 16 Nov 2019 08:51:15 +0100

> On 16. Nov 2019, at 02:07, Vineet Banga <vineetbanga=[email-masked]> wrote:
> 
> 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?

> 
> 
> On Wed, Nov 6, 2019 at 12:27 AM Hannes Tschofenig <[email-masked]> wrote:
> Hi all,
>

---

From: Vineet Banga <[email-masked]>
Date: Sat, 16 Nov 2019 13:42:39 -0800

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.

> 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 19 Nov 2019 10:25:34 +0800

> On 17. Nov 2019, at 05:42, Vineet Banga <[email-masked]> wrote:
> 
> 
> On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt <[email-masked]> wrote:
> 
> 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?

---

From: Vineet Banga <[email-masked]>
Date: Tue, 19 Nov 2019 13:38:49 +0800

> >
> > >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.

> 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 <
[email-masked]> wrote:

> > >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.
> >
> 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?
>
> >
> >
> >
> >
> >
> > >
> > >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 19 Nov 2019 14:17:02 +0800

> Am 19.11.2019 um 13:39 schrieb Vineet Banga <[email-masked]>:
> 
> 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. 

got you, thanks for the clarification.

I would recommend to use PKCE for CSRF prevention and state for representing the application state.

best regards,
Torsten.