Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Hans Zandbelt]

I think of this as somewhat similar to:
a)  a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP token introspection endpoint" where the cookie is introspected at
the RP and associated tokens are returned

if anyone comes up with a better name for this model and endpoint (and
probably less overloading of AS endpoint names...) and/or is willing to
help writing this down, please come forward and we'll pick it up on a new
thread/doc

Hans.

On Tue, Nov 20, 2018 at 11:00 PM George Fletcher  wrote:

> +1
>
> This model is useful and should be documented in its own right. Once
> documented it could possibly be referenced in the BCP.
>
> On 11/9/18 1:44 PM, David Waite wrote:
>
> Hi Hans, I hope it is acceptable to reply to your message on-list.
>
> Others could correct me if I am wrong, but I believe the purpose of this
> document is to recommend uses of other OAuth/OIDC specifications, not to
> include its own technologies.
>
> In terms of being another spec to be referenced, I think it would be
> useful but I wonder hypothetically how to best write that specification.
> This method seems to be relying on standards-defined tokens and converting
> them to an application server session, which isn’t defined by behavior
> other than HTTP cookies. The session info hook then lets you use those
> proprietary session tokens to retrieve the access/id token.
>
> As such, it is closer to an architecture for implementing a client - as a
> confidential client backend with an associated SPA frontend that needs to
> make OAuth-protected calls. It is not describing the communication between
> existing OAuth roles, such as between the client and AS.
>
> There’s obvious value here, and it's one of several architectures for
> browser-based apps using a confidential client rather than a public one
> (another example being a reverse proxy which maps remote OAuth endpoints
> into local, session-token-protected ones). I personally am just not sure
> how you would define the communication between back-end and front-end
> portions of the client in these architectures as a standard within OAuth.
>
> -DW
>
> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt 
> wrote:
>
> Hi Aaron, DW,
>
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the
> standardization of a "session info" endpoint (I'm open for better naming
> ;-)) as described in:
>
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>
> this approach is not just something that I cooked up; it is based on real
> world requests & deployments at Netflix and OAth.
>
> Let me know what you think,
>
> Hans.
>
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
>> Hi all,
>>
>> Today we were not able to talk about
>> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for
>> Browser-Based Apps".
>>
>> Aaron put a few slides together, which can be found here:
>>
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>>
>> Your review of this new draft is highly appreciated.
>>
>> Ciao
>> Hannes
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



--
DISCUSS:
--

Thanks to everyone who worked on this document. I have a blocking issue that
should be easy to resolve, and a handful of more minor issues.

§2.1:

>  The client makes a token exchange request to the token endpoint with
>  an extension grant type by including the following parameters using
>  the "application/x-www-form-urlencoded" format

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as this
appears to be the most recent stable description of how to encode this media
type. I'd love to hear rationale behind other citations being more appropriate,
since I'm not entirely happy with the one I suggest above (given that it's been
superseded by HTML 5.2); but every other plausible citation I can find is even
less palatable (with HTML 5.2 itself having the drawback of not actually
defining how to encode the media type, instead pointing to an unstable,
unversioned document).


--
COMMENT:
--

Abstract:

>  This specification defines a protocol for an HTTP- and JSON- based

Nit: "...JSON-based..."

---

§1.1:

>  impersonates principal B, then in so far as any entity receiving such

Nit: "insofar"

---

§2.1:

>  The client makes a token exchange request to the token endpoint with
>  an extension grant type by including the following parameters using
>  the "application/x-www-form-urlencoded" format with a character
>  encoding of UTF-8 in the HTTP request entity-body:

I think there's an implication here that POST is used, but that probably needs
to be made explicit.

---

§2.2.1:

>  response using the "application/json" media type, as specified by
>  [RFC7159], and an HTTP 200 status code.  The parameters are

RFC 7159 has been replaced by RFC 8259.

---

§3:

>  urn:ietf:params:oauth:token-type:refresh_token
> Indicates that the token is an OAuth 2.0 refreshe token issued by

nit: "refresh"


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

All important points. I'm not sure it affects whether refresh_tokens 
should be bound to the authenticated session or not. If using a 
continuous authentication model, it just means that as long as the AS/OP 
believes the authentication session is valid, the refresh_token will 
also continue to be valid. When the authentication session is determined 
to be invalid, then the refresh_token is also revoked. In this 
"continuous authentication" model, it feels like forcing the user to 
re-authenticate would be a last resort. Instead other mechanisms would 
be used to increase the confidence that the identified user is correct.


On 11/20/18 5:47 PM, David Waite wrote:



On Nov 20, 2018, at 1:37 PM, Aaron Parecki > wrote:


The new section on refresh tokens is great! I have a couple 
questions/comments about some of the details.


Authorization servers may revoke refresh tokens automatically in case
of a security event, such as:
o  logout at the authorization server

This doesn't sound like the desired behavior for mobile apps, where 
the user's expectation of how long they are logged in to the mobile 
app is not tied to their web session where they authorized the app. 
However this does likely match a user's expectation when authorizing 
a browser-based app. Should this be clarified that it should not 
apply to the mobile app case, or only apply to browser-based apps?


There is also the model where web sessions are perpetual; where you 
are evaluating access against a confidence that it is the legitimate 
user against known threats. In that model, you require authentication 
(perhaps by invalidating a client’s access and refresh tokens) as 
needed to rebuild that confidence.


This still is considered an online model; the offline model would be 
distinguished by evaluating the confidence that a client is still 
trusted and acting in the user’s interests.


In terms of user-initiated logout - logout is an interesting action, 
with both broad and miscommunicated purpose. I’ve found three 
different verbalizations of why a user hits this button:


1. It must be here for some reason, so I think I’m supposed to hit it 
when I’m done (aka 'security hygiene')
2. I suspect I might not be the next person who interacts with this 
device, so you should ask me who I am before allowing future access 
(aka ‘is this still you’)
3. I want software on this device to stop being able to access my 
accounts, and to destroy any cached information (aka ‘kill switch’)


All could be expected to stop access by online clients, while someone 
operating under expectation #3 could extend even to stopping offline 
access.


Likewise, it could be said that users with expectation #2 would resume 
access with previous scopes after an authentication, while expectation 
#3 would imply a need to reestablish consent to resume.


-DW


___
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] I-D Action: draft-ietf-oauth-security-topics-10.txt

[David Waite]

> On Nov 20, 2018, at 1:37 PM, Aaron Parecki  wrote:
> 
> The new section on refresh tokens is great! I have a couple 
> questions/comments about some of the details.
> 
> Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o  logout at the authorization server
>  
> This doesn't sound like the desired behavior for mobile apps, where the 
> user's expectation of how long they are logged in to the mobile app is not 
> tied to their web session where they authorized the app. However this does 
> likely match a user's expectation when authorizing a browser-based app. 
> Should this be clarified that it should not apply to the mobile app case, or 
> only apply to browser-based apps?

There is also the model where web sessions are perpetual; where you are 
evaluating access against a confidence that it is the legitimate user against 
known threats. In that model, you require authentication (perhaps by 
invalidating a client’s access and refresh tokens) as needed to rebuild that 
confidence.

This still is considered an online model; the offline model would be 
distinguished by evaluating the confidence that a client is still trusted and 
acting in the user’s interests.

In terms of user-initiated logout - logout is an interesting action, with both 
broad and miscommunicated purpose. I’ve found three different verbalizations of 
why a user hits this button:

1. It must be here for some reason, so I think I’m supposed to hit it when I’m 
done (aka 'security hygiene')
2. I suspect I might not be the next person who interacts with this device, so 
you should ask me who I am before allowing future access (aka ‘is this still 
you’)
3. I want software on this device to stop being able to access my accounts, and 
to destroy any cached information (aka ‘kill switch’)

All could be expected to stop access by online clients, while someone operating 
under expectation #3 could extend even to stopping offline access.

Likewise, it could be said that users with expectation #2 would resume access 
with previous scopes after an authentication, while expectation #3 would imply 
a need to reestablish consent to resume.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

Thanks for the additional section on refresh_tokens. Some additional 
recommendations...


1. By default refresh_tokens are bound to the user's authenticated 
session. When the authenticated session expires or is terminated 
(whether by the user or for some other reason) the refresh_tokenis 
implicitly revoked.
2. Clients that need to obtain a refresh_token that exists beyond the 
lifetime of the user's authentication session MUST indicate this need by 
requesting the "offline_access" scope 
(https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). 
This provides for a user consent event making it clear to the user that 
the client is requesting access even when the user's authentication 
session expires. This then becomes the default for mobile apps as the 
refresh_token should not be tied to the web session used to authorize 
the app.
3. The AS MAY consider putting an upper bound on the lifetime of a 
refresh_token (e.g. 1 year). There is no real need to issue a 
refresh_token that is good indefinitely.


This is in addition to the other best practices described.

Thanks,
George

On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:

Hi all,

the new revision contains the following changes:

* added section on refresh tokens
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up 
(based on feedback by Joseph Heenan)
* added requirement to authenticate clients during code exchange (PKCE or 
client credential) to 2.1.1.
* changed occurrences of SHALL to MUST

As always: looking forward for your feedback.

kind regards,
Torsten.


Am 20.11.2018 um 20:26 schrieb internet-dra...@ietf.org:


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-10.txt
Pages   : 38
Date: 2018-11-20

Abstract:
   This document describes best current security practice 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-10
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10

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


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/

___
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] OAuth Security Topics -- Recommend authorization code instead of implicit

[John Bradley]

Post response works OK for server based clients.  I don't think POST works
for single page applications.

Basically that would be something more like postmessage between two JS
apps.

Postmessage also has security issues passing a access token and leaking.

Perhaps someone more familiar with SPA can comment on POST.

John B.



On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it
> doesn't prevent the token from traversing through the browser. So a
> man-in-the-browser attack may be able to intercept the values. It should
> help with leakage in logs.
>
> Thanks,
> George
>
> On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question – doesn’t using the Form Post Response Mode
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> mitigate the threats you’re describing below John?  If so, I believe the
> Security Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is
> why I believe that describing profiles using ID Tokens and the Form Post
> Response Mode are in scope.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth   *On
> Behalf Of * John Bradley
> *Sent:* Tuesday, November 20, 2018 7:47 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
>
>
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs or
> redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say
> sending it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
>
>
> I agree that OIDC hybrid flows offer additional security over the OAuth 
> implicit grant and are used in the wild. On my slides and in the initial 
> version of the new section, we had included the hybrid OIDC flows because of 
> their known token injection countermeasures.
>
>
>
> I nevertheless feel very uncomfortable to recommend those flows and any flow 
> issuing access tokens in the front channel. In the course of the detailed 
> review of the new text we realized two issues:
>
>
>
> 1) Since the access token is exposed in the URL, such flows possess a 
> significantly higher risk to leak the access token (e.g. through browser 
> history, open redirection and even referrer headers) than the code grant.
>
> 2) There is no viable way to sender constrain access tokens issued in the 
> front channel. Given the WG decided to recommend use of sender constraint 
> tokens 
> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
>  it seems contradictory to recommend response types not supporting such an 
> approach.
>
>
>
> kind regards,
>
> Torsten.
>
>
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones 
>  
> :
>
>
>
> This description of the situation is an oversimplification.  OpenID Connect 
> secures the implicit flow against token injection attacks by including the 
> at_hash (access token hash) in the ID Token, enabling the client to validate 
> that the access token was created by the issuer in the ID Token (which is 
> also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation 
> was described in draft-ietf-oauth-mix-up-mitigation.)
>
>  Given the prevalence of this known-good solution for securing the implicit 
> flow, I would request that the draft be updated to describe this mitigation.  
> At the same time, I’m fine with the draft recommending the code flow over the 
> implicit flow when this mitigation is not used.
>
>  Thank you,
>
> -- Mike
>
>  From: OAuth   On Behalf Of 
> Hannes Tschofenig
>
> Sent: Monday, November 19, 2018 2:34 AM
>
> To: oauth  
>
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>
>  Hi all,
>
>  The authors of the OAuth Security Topics draft came to the conclusion that 
> it is not possible to adequately secure the implicit flow against token 
> injection since potential solutions like token binding or JARM are in an 
> early stage of adoption. For this reason, and since CORS allows browser-based 
> apps to send requests to the token endpoint, Torsten suggested to use the 
> authorization code instead of the implicit grant in call cases in his 
> presentation 
> (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
>  A hum in the room at IETF#103 concluded strong support for his 
> recommendations. We would like to confirm the discussion on the list.
>
>  Please provide a response by December 3rd.
>
>  Ciao
>
> Hannes & Rifaat
>
>  IMPORTANT NOTICE: The contents of this email and any attachments are 
> 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[George Fletcher]

+1

This model is useful and should be documented in its own right. Once 
documented it could possibly be referenced in the BCP.


On 11/9/18 1:44 PM, David Waite wrote:

Hi Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me if I am wrong, but I believe the purpose of 
this document is to recommend uses of other OAuth/OIDC specifications, 
not to include its own technologies.


In terms of being another spec to be referenced, I think it would be 
useful but I wonder hypothetically how to best write that 
specification. This method seems to be relying on standards-defined 
tokens and converting them to an application server session, which 
isn’t defined by behavior other than HTTP cookies. The session info 
hook then lets you use those proprietary session tokens to retrieve 
the access/id token.


As such, it is closer to an architecture for implementing a client - 
as a confidential client backend with an associated SPA frontend that 
needs to make OAuth-protected calls. It is not describing the 
communication between existing OAuth roles, such as between the client 
and AS.


There’s obvious value here, and it's one of several architectures for 
browser-based apps using a confidential client rather than a public 
one (another example being a reverse proxy which maps remote OAuth 
endpoints into local, session-token-protected ones). I personally am 
just not sure how you would define the communication between back-end 
and front-end portions of the client in these architectures as a 
standard within OAuth.


-DW

On Nov 6, 2018, at 3:03 AM, Hans Zandbelt > wrote:


Hi Aaron, DW,

About draft-parecki-oauth-browser-based-apps:
would you consider including a recommendation about and the 
standardization of a "session info" endpoint (I'm open for better 
naming ;-)) as described in:

https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/

this approach is not just something that I cooked up; it is based on 
real world requests & deployments at Netflix and OAth.


Let me know what you think,

Hans.

On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:


Hi all,

Today we were not able to talk about
draft-parecki-oauth-browser-based-apps-00, which describes 
"OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:

https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
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
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



--
hans.zandb...@zmartzone.eu 
ZmartZone IAM - www.zmartzone.eu 




___
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] OAuth Security Topics -- Recommend authorization code instead of implicit

[George Fletcher]

Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but 
it doesn't prevent the token from traversing through the browser. So a 
man-in-the-browser attack may be able to intercept the values. It should 
help with leakage in logs.


Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:


Next question – doesn’t using the Form Post Response Mode 
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html 
mitigate the threats you’re describing below John?  If so, I believe 
the Security Topics draft should say this.


I believe we owe it to readers to present the complete picture, which 
is why I believe that describing profiles using ID Tokens and the Form 
Post Response Mode are in scope.


-- Mike

*From:* OAuth  *On Behalf Of * John Bradley
*Sent:* Tuesday, November 20, 2018 7:47 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend 
authorization code instead of implicit


Yes the at_hash protects the client from accepting an injected AT.

Unfortunately it doesn't do anything to protect against leakage in 
logs or redirects.


So without the AT using some sort of POP mechanism it is hard to say 
sending it in a redirect is a good security practice.


John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,

I agree that OIDC hybrid flows offer additional security over the OAuth 
implicit grant and are used in the wild. On my slides and in the initial 
version of the new section, we had included the hybrid OIDC flows because of 
their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any 
flow issuing access tokens in the front channel. In the course of the detailed 
review of the new text we realized two issues:

1) Since the access token is exposed in the URL, such flows possess a 
significantly higher risk to leak the access token (e.g. through browser 
history, open redirection and even referrer headers) than the code grant.

2) There is no viable way to sender constrain access tokens issued in the 
front channel. Given the WG decided to recommend use of sender constraint 
tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), 
it seems contradictory to recommend response types not supporting such an 
approach.

kind regards,

Torsten.

Am 19.11.2018 um 23:13 schrieb Mike 
Jones
:

This description of the situation is an oversimplification.  OpenID 
Connect secures the implicit flow against token injection attacks by including 
the at_hash (access token hash) in the ID Token, enabling the client to 
validate that the access token was created by the issuer in the ID Token (which 
is also the OAuth Issuer, as described in RFC 8414).  (Note that this 
mitigation was described in draft-ietf-oauth-mix-up-mitigation.)

  


Given the prevalence of this known-good solution for securing the 
implicit flow, I would request that the draft be updated to describe this 
mitigation.  At the same time, I’m fine with the draft recommending the code 
flow over the implicit flow when this mitigation is not used.

  


 Thank 
you,

     -- Mike

  


From: OAuth   On 
Behalf Of Hannes Tschofenig

Sent: Monday, November 19, 2018 2:34 AM

To: oauth 

Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization 
code instead of implicit

  


Hi all,

  


The authors of the OAuth Security Topics draft came to the conclusion 
that it is not possible to adequately secure the implicit flow against token 
injection since potential solutions like token binding or JARM are in an early 
stage of adoption. For this reason, and since CORS allows browser-based apps to 
send requests to the token endpoint, Torsten suggested to use the authorization 
code instead of the implicit grant in call cases in his presentation 
(seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).

  


A hum in the room at IETF#103 concluded strong support for his 
recommendations. We would like to confirm the discussion on the list.

  


Please provide a response by December 3rd.

  


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.

Re: [OAUTH-WG] Refresh Token Expiration

[George Fletcher]

Hi Aaron,

We don't issue refresh_tokens for any implicit flow. So if a browser 
based app were to use the code flow, we would issue a refresh_token. 
Restricting which clients can receive refresh_tokens (or based on some 
other policy) is not a significant addition. However, for most browser 
apps, we have a module the relying party can deploy that handles all the 
code flow semantics on the server side and then the SPA can just request 
a new access_token from the server side module. The module also handles 
sessions management.


Personally, I'm not crazy about refresh_tokens being present in 
browsers. Browsers should just re-authorize if they can't use a 
server-side component for tokens management. OIDC provides a 
"prompt=none" mechanism that allows the browser app to request a new 
token in a hidden iframe. OAuth2 doesn't describe this flow. Note that 
full authentications of users should NOT happen in iframes due to 
click-jacking attacks.


Thanks,
George

On 11/20/18 3:56 PM, Aaron Parecki wrote:

Hi George,

Reading this description, am I understanding correctly that you 
*always* return a refresh token to every client? Are there any 
situations in which a refresh token would not be returned? 
Specifically I'm wondering about how this applies to browser-based 
apps using the authorization code flow and refresh tokens.



Aaron Parecki
aaronparecki.com 



On Tue, Nov 20, 2018 at 12:38 PM George Fletcher 
mailto:40aol@dmarc.ietf.org>> 
wrote:


Hi Torsten,

This is the model I much prefer. By default all refresh_tokens are
bound to the user's authenticated session. When the authentication
session is terminated, the refresh_tokens are invalidated. If a
client wants to get a refresh_token that is NOT bound to an
authentication session, then it much explicitly request the
"offline_access" scope which then provides a consent interaction
with the user which allows the user to know that this client wants
to access their resources even when the user isn't logged in
(present). This also provides the AS with the ability to control
which clients are authorized to request "offline_access" and hence
restrict that capability to know/approved clients.

We've implemented this module in two different Authorization Servers.

Thanks,
George

On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:

Hi all,

I‘m preparing a new section on Refresh Token best practices for the 
Security BCP. I‘m wondering whether anyone has implemented a binding of the 
refresh token‘s expiration/revocation with the state of the session the refresh 
token was issued in/for. So do you revoke refresh tokens when the user logs out 
from the AS or the session terminated for other reasons?

kinds regards,
Torsten.


___
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] OAuth Digest, Vol 121, Issue 48

[Adam Cashion]

On Tue, Nov 20, 2018, 2:56 PM  Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>1. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
>   (Aaron Parecki)
>2. Re: Refresh Token Expiration (George Fletcher)
>3. Re: Refresh Token Expiration (Aaron Parecki)
>
>
>
> -- Forwarded message --
> From: Aaron Parecki 
> To: Torsten Lodderstedt 
> Cc: OAuth WG 
> Bcc:
> Date: Tue, 20 Nov 2018 12:37:34 -0800
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
> The new section on refresh tokens is great! I have a couple
> questions/comments about some of the details.
>
> Authorization servers may revoke refresh tokens automatically in case
>> of a security event, such as:
>> o  logout at the authorization server
>
>
> This doesn't sound like the desired behavior for mobile apps, where the
> user's expectation of how long they are logged in to the mobile app is not
> tied to their web session where they authorized the app. However this does
> likely match a user's expectation when authorizing a browser-based app.
> Should this be clarified that it should not apply to the mobile app case,
> or only apply to browser-based apps?
>
> Refresh tokens should expire if the client has been inactive for some time
>
>
> This is a good suggestion, but I think it would benefit from a little more
> clarity. Specifically pointing out that what counts as "activity" is use of
> the access token and/or refresh token, if that's the intention. That will
> help avoid confusion that "inactivity" may be referring to the user's
> session at the authorization server.
>
> Is this supposed to be a capital "SHOULD" or lowercase "should"?
>
> It is also unclear whether this is meant to apply to public clients,
> private clients, or both, as well as whether it should apply to mobile apps
> or browser-based apps or both. I am curious what the intent is here, since
> I feel like that can have some serious implications for the user experience
> in some cases and is worth pointing out.
>
> Lastly, minor nit, I see the comment about changing occurrences of "SHALL"
> to "MUST", but the new refresh token section still has two uses of "SHALL".
>
> Thanks! Overall I'm happy to see this guidance!
>
> 
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> the new revision contains the following changes:
>>
>> * added section on refresh tokens
>> * additional justifications for recommendation for code
>> * refactored 2.1 in order to distinguish CSRF, authz response replay and
>> mix-up (based on feedback by Joseph Heenan)
>> * added requirement to authenticate clients during code exchange (PKCE or
>> client credential) to 2.1.1.
>> * changed occurrences of SHALL to MUST
>>
>> As always: looking forward for your feedback.
>>
>> kind regards,
>> Torsten.
>>
>> > Am 20.11.2018 um 20:26 schrieb internet-dra...@ietf.org:
>> >
>> >
>> > 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-10.txt
>> >   Pages   : 38
>> >   Date: 2018-11-20
>> >
>> > Abstract:
>> >   This document describes best current security practice 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-10
>> >
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
>> >
>> >
>> > 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.
>> >
>> > 

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Mike Jones]

Next question – doesn’t using the Form Post Response Mode 
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the 
threats you’re describing below John?  If so, I believe the Security Topics 
draft should say this.

I believe we owe it to readers to present the complete picture, which is why I 
believe that describing profiles using ID Tokens and the Form Post Response 
Mode are in scope.

   -- Mike

From: OAuth  On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit


Yes the at_hash protects the client from accepting an injected AT.

Unfortunately it doesn't do anything to protect against leakage in logs or 
redirects.

So without the AT using some sort of POP mechanism it is hard to say sending it 
in a redirect is a good security practice.

John B.
On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,



I agree that OIDC hybrid flows offer additional security over the OAuth 
implicit grant and are used in the wild. On my slides and in the initial 
version of the new section, we had included the hybrid OIDC flows because of 
their known token injection countermeasures.



I nevertheless feel very uncomfortable to recommend those flows and any flow 
issuing access tokens in the front channel. In the course of the detailed 
review of the new text we realized two issues:



1) Since the access token is exposed in the URL, such flows possess a 
significantly higher risk to leak the access token (e.g. through browser 
history, open redirection and even referrer headers) than the code grant.

2) There is no viable way to sender constrain access tokens issued in the front 
channel. Given the WG decided to recommend use of sender constraint tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), 
it seems contradictory to recommend response types not supporting such an 
approach.



kind regards,

Torsten.



Am 19.11.2018 um 23:13 schrieb Mike Jones 
:



This description of the situation is an oversimplification.  OpenID Connect 
secures the implicit flow against token injection attacks by including the 
at_hash (access token hash) in the ID Token, enabling the client to validate 
that the access token was created by the issuer in the ID Token (which is also 
the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was 
described in draft-ietf-oauth-mix-up-mitigation.)



Given the prevalence of this known-good solution for securing the implicit 
flow, I would request that the draft be updated to describe this mitigation.  
At the same time, I’m fine with the draft recommending the code flow over the 
implicit flow when this mitigation is not used.



Thank you,

-- Mike



From: OAuth  On Behalf 
Of Hannes Tschofenig

Sent: Monday, November 19, 2018 2:34 AM

To: oauth 

Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit



Hi all,



The authors of the OAuth Security Topics draft came to the conclusion that it 
is not possible to adequately secure the implicit flow against token injection 
since potential solutions like token binding or JARM are in an early stage of 
adoption. For this reason, and since CORS allows browser-based apps to send 
requests to the token endpoint, Torsten suggested to use the authorization code 
instead of the implicit grant in call cases in his presentation 
(seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).



A hum in the room at IETF#103 concluded strong support for his recommendations. 
We would like to confirm the discussion on the list.



Please provide a response by December 3rd.



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

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] Refresh Token Expiration

[Aaron Parecki]

Hi George,

Reading this description, am I understanding correctly that you *always*
return a refresh token to every client? Are there any situations in which a
refresh token would not be returned? Specifically I'm wondering about how
this applies to browser-based apps using the authorization code flow and
refresh tokens.


Aaron Parecki
aaronparecki.com



On Tue, Nov 20, 2018 at 12:38 PM George Fletcher  wrote:

> Hi Torsten,
>
> This is the module I much prefer. By default all refresh_tokens are bound
> to the user's authenticated session. When the authentication session is
> terminated, the refresh_tokens are invalidated. If a client wants to get a
> refresh_token that is NOT bound to an authentication session, then it much
> explicitly request the "offline_access" scope which then provides a consent
> interaction with the user which allows the user to know that this client
> wants to access their resources even when the user isn't logged in
> (present). This also provides the AS with the ability to control which
> clients are authorized to request "offline_access" and hence restrict that
> capability to know/approved clients.
>
> We've implemented this module in two different Authorization Servers.
>
> Thanks,
> George
>
> On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
>
> Hi all,
>
> I‘m preparing a new section on Refresh Token best practices for the Security 
> BCP. I‘m wondering whether anyone has implemented a binding of the refresh 
> token‘s expiration/revocation with the state of the session the refresh token 
> was issued in/for. So do you revoke refresh tokens when the user logs out 
> from the AS or the session terminated for other reasons?
>
> kinds regards,
> Torsten.
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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] Refresh Token Expiration

[George Fletcher]

Hi Torsten,

This is the module I much prefer. By default all refresh_tokens are 
bound to the user's authenticated session. When the authentication 
session is terminated, the refresh_tokens are invalidated. If a client 
wants to get a refresh_token that is NOT bound to an authentication 
session, then it much explicitly request the "offline_access" scope 
which then provides a consent interaction with the user which allows the 
user to know that this client wants to access their resources even when 
the user isn't logged in (present). This also provides the AS with the 
ability to control which clients are authorized to request 
"offline_access" and hence restrict that capability to know/approved 
clients.


We've implemented this module in two different Authorization Servers.

Thanks,
George

On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:

Hi all,

I‘m preparing a new section on Refresh Token best practices for the Security 
BCP. I‘m wondering whether anyone has implemented a binding of the refresh 
token‘s expiration/revocation with the state of the session the refresh token 
was issued in/for. So do you revoke refresh tokens when the user logs out from 
the AS or the session terminated for other reasons?

kinds regards,
Torsten.


___
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] OAuth Digest, Vol 121, Issue 45

[Adam Cashion]

email

On Tue, Nov 20, 2018, 1:37 PM  Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>1. Re: OAuth Security Topics -- Recommend authorization code
>   instead of implicit (John Bradley)
>2. I-D Action: draft-ietf-oauth-security-topics-10.txt
>   (internet-dra...@ietf.org)
>3. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
>   (Torsten Lodderstedt)
>4. Re: Token Binding & implicit (Torsten Lodderstedt)
>
>
>
> -- Forwarded message --
> From: John Bradley 
> To: oauth@ietf.org
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 12:47:22 -0300
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs or
> redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say
> sending it in a redirect is a good security practice.
>
> John B.
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth 
> implicit grant and are used in the wild. On my slides and in the initial 
> version of the new section, we had included the hybrid OIDC flows because of 
> their known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any flow 
> issuing access tokens in the front channel. In the course of the detailed 
> review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a 
> significantly higher risk to leak the access token (e.g. through browser 
> history, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the 
> front channel. Given the WG decided to recommend use of sender constraint 
> tokens 
> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
>  it seems contradictory to recommend response types not supporting such an 
> approach.
>
> kind regards,
> Torsten.
>
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones 
>  
> :
>
> This description of the situation is an oversimplification.  OpenID Connect 
> secures the implicit flow against token injection attacks by including the 
> at_hash (access token hash) in the ID Token, enabling the client to validate 
> that the access token was created by the issuer in the ID Token (which is 
> also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation 
> was described in draft-ietf-oauth-mix-up-mitigation.)
>
> Given the prevalence of this known-good solution for securing the implicit 
> flow, I would request that the draft be updated to describe this mitigation.  
> At the same time, I’m fine with the draft recommending the code flow over the 
> implicit flow when this mitigation is not used.
>
> Thank you,
> -- Mike
>
> From: OAuth   On Behalf Of 
> Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth  
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> instead of implicit
>
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion that it 
> is not possible to adequately secure the implicit flow against token 
> injection since potential solutions like token binding or JARM are in an 
> early stage of adoption. For this reason, and since CORS allows browser-based 
> apps to send requests to the token endpoint, Torsten suggested to use the 
> authorization code instead of the implicit grant in call cases in his 
> presentation 
> (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his 
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> 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 

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

[Aaron Parecki]

The new section on refresh tokens is great! I have a couple
questions/comments about some of the details.

Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o  logout at the authorization server


This doesn't sound like the desired behavior for mobile apps, where the
user's expectation of how long they are logged in to the mobile app is not
tied to their web session where they authorized the app. However this does
likely match a user's expectation when authorizing a browser-based app.
Should this be clarified that it should not apply to the mobile app case,
or only apply to browser-based apps?

Refresh tokens should expire if the client has been inactive for some time


This is a good suggestion, but I think it would benefit from a little more
clarity. Specifically pointing out that what counts as "activity" is use of
the access token and/or refresh token, if that's the intention. That will
help avoid confusion that "inactivity" may be referring to the user's
session at the authorization server.

Is this supposed to be a capital "SHOULD" or lowercase "should"?

It is also unclear whether this is meant to apply to public clients,
private clients, or both, as well as whether it should apply to mobile apps
or browser-based apps or both. I am curious what the intent is here, since
I feel like that can have some serious implications for the user experience
in some cases and is worth pointing out.

Lastly, minor nit, I see the comment about changing occurrences of "SHALL"
to "MUST", but the new refresh token section still has two uses of "SHALL".

Thanks! Overall I'm happy to see this guidance!


Aaron Parecki
aaronparecki.com



On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi all,
>
> the new revision contains the following changes:
>
> * added section on refresh tokens
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay and
> mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE or
> client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>
> As always: looking forward for your feedback.
>
> kind regards,
> Torsten.
>
> > Am 20.11.2018 um 20:26 schrieb internet-dra...@ietf.org:
> >
> >
> > 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-10.txt
> >   Pages   : 38
> >   Date: 2018-11-20
> >
> > Abstract:
> >   This document describes best current security practice 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-10
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
> >
> >
> > 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/
> >
> > ___
> > 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] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[George Fletcher]

In regards to the comment on section 4.1, it depends on the 
authorization policy and the deployment architecture. I don't believe 
there is a single solution that will work with all deployments.


It may be worth calling out that exposure of the entire delegation chain 
can leak information and that care should be taken to ensure the entity 
receiving the token with this information is in fact authorized to 
receive it.


On 11/20/18 2:50 PM, Alissa Cooper wrote:

Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



--
DISCUSS:
--

Section 6: The requirements around confidentiality here are weaker than in both
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?


--
COMMENT:
--

Section 3:

If I understand this correctly:

"The distinction between an access token and a JWT is subtle."

I think it would be clearer if it said:

"The distinction between an access token type and a JWT token type is subtle."

Section 4.1:

What is the value of maintaining the whole delegation chain rather than
expressing just the most recent delegation? Doesn't it potentially expose
information about past exchanges unnecessarily?


___
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] Token Binding & implicit

[Aaron Parecki]

Agreed with 4. Since the security BCP is deprecating the implicit flow, it
seems like it's not worth the effort to try to come up with a solution for
this when the security implications of doing this aren't clear yet either.


Aaron Parecki
aaronparecki.com

On Tue, Nov 20, 2018 at 11:36 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> I opt for (4) - Remove support/description of binding of access tokens
> issued from the authorization endpoint
>
> I think the potential solution we worked out (slide 6) is to complex and
> the security implications of the redirect via the resource servers are
> still unclear.
>
> > Am 18.11.2018 um 13:32 schrieb Brian Campbell  40pingidentity@dmarc.ietf.org>:
> >
> > During the first OAuth session in Bangkok the question "what to do about
> token binding & implicit?" was raised. There was some discussion but
> session time was limited and we had to move on before any real consensus
> was reached.
> >
> > So I thought I'd bring the question to the WG list to generate some more
> discussion on the issue. It's also related, at least in part, to a couple
> of the other ongoing threads on the list about browser based apps and
> security practices.
> >
> > The slides from the session are linked below. Slides 5 & 6 try and
> explain the awkwardness of doing Token Binding with implicit. While slide 7
> lays out some (not very good) options for how to proceed.
> >
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
> >
> > 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
>
> ___
> 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] [Gen-art] Genart last call review of draft-ietf-oauth-token-exchange-14

[Alissa Cooper]

Jari, thanks for your review. Brian, thanks for your response. I flagged the 
issue Jari raises below in my DISCUSS ballot — it’s not clear to me why there 
aren’t normative requirements around confidentiality as there are in the JWT 
spec and the OAuth 2.0 spec.

Thanks,
Alissa

> On Aug 10, 2018, at 3:49 PM, Brian Campbell 
>  wrote:
> 
> Thanks for the review Jari,
> 
> Regarding minimizing details, I'm thinking that incorporating some text along 
> the lines of what's in the Privacy Considerations of RFC 7523 
>  might be a worthwhile 
> addition.  
> 
> 
> On Fri, Aug 3, 2018 at 7:49 AM Jari Arkko  > wrote:
> Reviewer: Jari Arkko
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-oauth-token-exchange-14
> Reviewer: Jari Arkko
> Review Date: 2018-08-03
> IETF LC End Date: 2018-08-06
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This specification describes a standardised protocol for requesting and
> receiving security tokens from an OAuth 2.0 authorisation service.
> 
> I had no experience on OAuth previously, but the document was understandable
> and as far as I could determine, had no major issues.
> 
> It was a bit more difficult to determine completeness.  Security and privacy
> considerations sections were quite short, for instance, and maybe that's
> justifiable given the ability to refer to prior RFCs on this subject. However,
> I suspect one could say more, e.g., Section 7 says "Tokens typically carry
> personal information and their usage in Token Exchange may  reveal details of
> the target services being accessed", but it does not offer any advice on how
> such details might be minimised. But perhaps that's already in another RFC as
> well.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 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.___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



--
DISCUSS:
--

Section 6: The requirements around confidentiality here are weaker than in both
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?


--
COMMENT:
--

Section 3:

If I understand this correctly:

"The distinction between an access token and a JWT is subtle."

I think it would be clearer if it said:

"The distinction between an access token type and a JWT token type is subtle."

Section 4.1:

What is the value of maintaining the whole delegation chain rather than
expressing just the most recent delegation? Doesn't it potentially expose
information about past exchanges unnecessarily?


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Binding & implicit

[Torsten Lodderstedt]

I opt for (4) - Remove support/description of binding of access tokens issued 
from the authorization endpoint 

I think the potential solution we worked out (slide 6) is to complex and the 
security implications of the redirect via the resource servers are still 
unclear.

> Am 18.11.2018 um 13:32 schrieb Brian Campbell 
> :
> 
> During the first OAuth session in Bangkok the question "what to do about 
> token binding & implicit?" was raised. There was some discussion but session 
> time was limited and we had to move on before any real consensus was reached. 
> 
> So I thought I'd bring the question to the WG list to generate some more 
> discussion on the issue. It's also related, at least in part, to a couple of 
> the other ongoing threads on the list about browser based apps and security 
> practices. 
> 
> The slides from the session are linked below. Slides 5 & 6 try and explain 
> the awkwardness of doing Token Binding with implicit. While slide 7 lays out 
> some (not very good) options for how to proceed.
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
> 
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi all, 

the new revision contains the following changes:

* added section on refresh tokens 
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up 
(based on feedback by Joseph Heenan)
* added requirement to authenticate clients during code exchange (PKCE or 
client credential) to 2.1.1.
* changed occurrences of SHALL to MUST

As always: looking forward for your feedback.

kind regards,
Torsten. 

> Am 20.11.2018 um 20:26 schrieb internet-dra...@ietf.org:
> 
> 
> 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-10.txt
>   Pages   : 38
>   Date: 2018-11-20
> 
> Abstract:
>   This document describes best current security practice 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-10
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
> 
> 
> 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/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[internet-drafts]

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-10.txt
Pages   : 38
Date: 2018-11-20

Abstract:
   This document describes best current security practice 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-10
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10

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


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/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[John Bradley]

Yes the at_hash protects the client from accepting an injected AT.

Unfortunately it doesn't do anything to protect against leakage in logs 
or redirects.


So without the AT using some sort of POP mechanism it is hard to say 
sending it in a redirect is a good security practice.


John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,

I agree that OIDC hybrid flows offer additional security over the OAuth 
implicit grant and are used in the wild. On my slides and in the initial 
version of the new section, we had included the hybrid OIDC flows because of 
their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flow 
issuing access tokens in the front channel. In the course of the detailed 
review of the new text we realized two issues:

1) Since the access token is exposed in the URL, such flows possess a 
significantly higher risk to leak the access token (e.g. through browser 
history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front 
channel. Given the WG decided to recommend use of sender constraint tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), 
it seems contradictory to recommend response types not supporting such an 
approach.

kind regards,
Torsten.


Am 19.11.2018 um 23:13 schrieb Mike Jones 
:

This description of the situation is an oversimplification.  OpenID Connect 
secures the implicit flow against token injection attacks by including the 
at_hash (access token hash) in the ID Token, enabling the client to validate 
that the access token was created by the issuer in the ID Token (which is also 
the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was 
described in draft-ietf-oauth-mix-up-mitigation.)
  
Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
  
 Thank you,

 -- Mike
  
From: OAuth  On Behalf Of Hannes Tschofenig

Sent: Monday, November 19, 2018 2:34 AM
To: oauth 
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit
  
Hi all,
  
The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
  
A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
  
Please provide a response by December 3rd.
  
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
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] OAuth Digest, Vol 121, Issue 43

[Adam Cashion]

On Tue, Nov 20, 2018, 6:25 AM  Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>1. Re: draft-parecki-oauth-browser-based-apps-00 (Aaron Parecki)
>2. Re: OAuth Security Topics -- Recommend authorization code
>   instead of implicit (Torsten Lodderstedt)
>3. Dynamic Client Registration - client_secret_expires_at
>   (Filip Skokan)
>4. Re: OAuth Security Topics -- Recommend authorization code
>   instead of implicit (Neil Madden)
>
>
>
> -- Forwarded message --
> From: Aaron Parecki 
> To: OAuth WG 
> Cc:
> Bcc:
> Date: Mon, 19 Nov 2018 18:09:03 -0800
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan  wrote:
>
>
>> It may be worth slightly rewording 7..2 as it may encourage a growing
>> misconception that all native apps must be public clients. With many
>> devices now having embedded HSMs, we’ve seen increasing interest in mobile
>> apps being dynamically (per-install) registered oauth2 private clients, and
>> that model has a lot of advantages. (I’m not sure if we might see a similar
>> model evolving for web apps.)
>>
>
> That's a great point, thanks. I've removed the reference to native apps
> being public clients since it doesn't really add anything to this spec if I
> have to caveat the description.
>
> On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> > > First of all the AS decides whether it issues refresh tokens or not.
>> Having the ability does not mean the AS must do it. If you feel it’s safer
>> to not do it. Fine.
>> > Sure, and this should be mentioned then somewhere (either in the
>> threats doc or in this proposed best practice doc). Not all end developers
>> using these protocols fully understand the ramifications.
>> @Aaron: I suggest this goes to the SPA BCP since this is client specific..
>
>
> Thanks, I agree that this document should include some recommendations
> around refresh token handling. Looking at the discussion in this thread, it
> seems there are a few different strategies folks are taking. Since it seems
> like there isn't a strong consensus, it sounds like this would be better
> suited for the "Security Considerations" section, and to not make
> MUST/SHOULD recommendations, but rather just point out the issues. Any
> thoughts on that before I take a stab at writing something?
>
> I've incorporated some of the other feedback here and published an updated
> version:
>
> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01
>
> Thanks for the feedback so far.
>
> ---
> Aaron Parecki
> https://aaronparecki.com
>
>
>
> -- Forwarded message --
> From: Torsten Lodderstedt 
> To: Mike Jones 
> Cc: Hannes Tschofenig , oauth 
> Bcc:
> Date: Tue, 20 Nov 2018 08:35:17 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth
> implicit grant and are used in the wild. On my slides and in the initial
> version of the new section, we had included the hybrid OIDC flows because
> of their known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any
> flow issuing access tokens in the front channel. In the course of the
> detailed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a
> significantly higher risk to leak the access token (e.g. through browser
> history, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the
> front channel. Given the WG decided to recommend use of sender constraint
> tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2),
> it seems contradictory to recommend response types not supporting such an
> approach.
>
> kind regards,
> Torsten.
>
> > Am 19.11.2018 um 23:13 schrieb Mike Jones  40microsoft@dmarc.ietf.org>:
> >
> > This description of the situation is an oversimplification.  OpenID
> Connect secures the implicit flow against token injection attacks by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
> >
> > Given 

[OAUTH-WG] Dynamic Client Registration - client_secret_expires_at

[Filip Skokan]

Hi all,

a recent query about expiring client credentials (secrets) got me thinking
about client_secret_expires_at client metadata from RFC 7591 used also in
7592 as well as OpenID Connect Dynamic Client Registration 1.0

*What does expired client secret (in the sense of client_secret_expires_at
with a non 0 value) mean beyond obviously not processing secret-based
client authentication (basic, post and client_secret_jwt) after the given
timestamp?* *Fingers Crossed* I'm hoping for your comments and experience
from existing deployments on the topic to shed some light on this for me
and maybe others too. Also that this doesn't get lost between the current
BCP/implicit discussions.

This is my best shot at an implementable policy when it comes to clients
with expired client secrets: *"all operations requiring a secret will be
rejected when an expired one is presented"*

   - it is not valid for client secret based endpoint auth (basic, post,
   client secret jwt), the AS will reject with 401 invalid_client in those
   cases
   - it will not be used for validating symmetrically signed request object
   (JAR), the AS will reject the authorization request with ...?
   - it will not be used by the AS to symmetrically sign id tokens,
   userinfo, introspection or authorization responses (JARM), the AS will
   reject the requests with ...?
   - anything else?



I feel this is reasonable interpretation and if so, are there appropriate
errors to return to clients (both front and back-channel) when an expired
secret is encountered during one of the operations that need it?

Thank you very much for your thoughts and comments.

Best,
Filip
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth