Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

From: [email-masked]
Date: Fri, 24 Aug 2018 02:51:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-07.txt
	Pages           : 33
	Date            : 2018-08-24

Abstract:
   This document describes best current security practices for OAuth
   2.0.  It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-07

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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 24 Aug 2018 11:57:23 +0200

Hi all, 

I just published a new revision of the OAuth Security BCP. 

Here is the list of changes:
* added section on access token privilege restriction based on comments from Johan Peeters
* incorporated findings of Doug McDorman (e.g. domains used in examples)
* added section on HTTP status codes for redirects

kind regards,
Torsten. 

> Am 24.08.2018 um 11:51 schrieb [email-masked]:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 27 Aug 2018 12:32:38 +0300

Thanks for the update!

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-07#section-3.7.1.3

Audience restricted access token:

In a multi-RS environment with aud-restricted token policy in place, how
should the AS respond to an authZ request with scope values that belong
to more than one RS?

Vladimir

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 27 Aug 2018 20:24:12 +0200

> Am 27.08.2018 um 11:32 schrieb Vladimir Dzhuvinov <[email-masked]>:
> 
> Thanks for the update!
> In a multi-RS environment with aud-restricted token policy in place, how should the AS respond to an authZ request with scope values that belong to more than one RS?
> 
That’s a really good question! 

I see the following options:
1) the AS may abort and require the client to request tokens for different RSs using multiple authz requests (not cool)
2) the AS mints an access token for one of the resource servers and indicates this in the scope parameter of the token response. The AS may additionally issue a refresh token for the complete scope
3) the client could indicate the target RS it wants to interact with in the first step (e.g. using the resource parameter introduced by the resource indicators draft). The rest could work like (2)

kinds regards,
Torsten.

---

From: George Fletcher <[email-masked]>
Date: Wed, 29 Aug 2018 09:38:31 -0400

Couldn't the AS issue a token where the audience restriction is a list? 
This is true of the id_token spec.

On 8/27/18 2:24 PM, Torsten Lodderstedt wrote:
>
>
> Am 27.08..2018 um 11:32 schrieb Vladimir Dzhuvinov 
> <[email-masked] <mailto:[email-masked]>>:
>
>> Thanks for the update!
>>
>> In a multi-RS environment with aud-restricted token policy in place, 
>> how should the AS respond to an authZ request with scope values that 
>> belong to more than one RS?
>>
> 1) the AS may abort and require the client to request tokens for 
> different RSs using multiple authz requests (not cool)
> 2) the AS mints an access token for one of the resource servers and 
> indicates this in the scope parameter of the token response. The AS 
> may additionally issue a refresh token for the complete scope
> 3) the client could indicate the target RS it wants to interact with 
> in the first step (e.g. using the resource parameter introduced by the 
> resource indicators draft). The rest could work like (2)
>
> kinds regards,
> Torsten..
>>
>> Vladimir
>>
>>>> Am 24.08.2018 um 11:51 [email-masked]:
>>>>
>>>>
>>>> until the htmlized version and diff are available attools.ietf.org <http://tools..ietf.org>.
>>>>
>> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Aug 2018 17:06:35 +0200

> Am 29.08.2018 um 15:38 schrieb George Fletcher <[email-masked]>:
> 
> Couldn't the AS issue a token where the audience restriction is a list? This is true of the id_token spec. 

Sure, it could. That's certainly better than an unconstraint access token. But the recommendation in the draft is to restrict tokens to a single server. 

The draft states: „In particular, access tokens SHOULD be restricted to certain resource servers, preferably to a single resource server."

>> Am 27.08..2018 um 11:32 schrieb Vladimir Dzhuvinov <[email-masked]>:
>> 
>>> Thanks for the update!
>>>>> until the htmlized version and diff are available at 
>>>>> tools.ietf.org
>>>>> .
>>>>>