[OAUTH-WG] Philippe de Ryck on the insecurities of OAuth in the browser

[Dominick Baier]

Good examples of bypassing some of the recommendations from the web BCP and
OAuth 2.1

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

[OAUTH-WG] Small bug in DPoP 12

[Dominick Baier]

Hi,

While implementing I found

Section 4.2 says

htu: The *HTTP* target URI (Section 7.1 of [RFC9110]), without query and
fragment parts, of the request to which the JWT is attached.


While Section 4.3 says

the htu claim matches the *HTTPS* URI value for the HTTP request in which
the JWT was received, ignoring any query and fragment parts


HTTP vs HTTPS

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

[OAUTH-WG] WebApp BCP thoughts

[Dominick Baier]

Hi Aaron et al,

I re-read the latest version of the web app BCP. For me it has become
increasingly hard to follow, and so I’m concerned that it’s even harder for
the target audience this document is intended for.

It seems that over time more and more content got accumulated which IMO
jumps straight to conclusions without giving a good pro/con breakdown. I
worry that it will be hard for someone with less experience to make the
right choices (or easy to do the wrong ones).

Given we both (and others here on that list) attended Philippe de Rycks
presentations at the OSW, I wonder if it wouldn’t make sense to start this
document with the browser attacker model. This would make it very clear
what an attacker is potentially able to do in the browser.

>From there this would lead to various risks/attacks like

• Session hijacking
• Access token exfiltration
• Refresh token exfiltration
• …

..and based on that there are different implementation/architecture choices
to make. Each implementation style helps in mitigating one or more of the
above attacks. None of them will solve them all of course.

I think this approach would make this document more useful and maybe you
can consider such a re-design.

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

[OAUTH-WG] Web apps BCP feedback

[Dominick Baier]

In 6.1 it says

"Additionally, the SameSite cookie attribute can be used to
prevent CSRF attacks, or alternatively, the application and API could
be written to use anti-CSRF tokens.”

“Prevent” is a bit strong.

SameSite only restricts cookies sent across site boundaries Iit does not
prevent CSRF attacks from within a site boundary. Scenarios could be a
compromised sub-domain, like sub-domain takeover or just some vulnerable
application co-located on the same site.

thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification

[Dominick Baier]

We have implemented it

https://duendesoftware.com/products/identityserver

———
Dominick Baier

On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef (
rifaat.s.i...@gmail.com) wrote:

All,

As part of the shepherd write-up for the OAuth 2.0 Authorization Server
Issuer Identification document, we need a list of implementations for this
specification.

Please, reply to this email on the list with any implementation details for
this document.

Regards,
 Rifaat

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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

No. But they are CSRF protected (either SameSite or anti-forgery) and
HttpOnly.

———
Dominick Baier

On 17. February 2021 at 21:08:37, Neil Madden (neil.mad...@forgerock.com)
wrote:

Do you eliminate the cookies too?

On 17 Feb 2021, at 19:50, Dominick Baier  wrote:


Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.

———
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:

While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier 
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell , Torsten Lodderstedt <
> tors...@lodderstedt.net>
> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *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 lis

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.

———
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:

While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier 
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell , Torsten Lodderstedt <
> tors...@lodderstedt.net>
> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *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] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Yes - “no OAuth tokens in the browser” ;) They are all kept server-side and
the BFF proxies the API calls if necessary. Also the RT management happens
server-side and is transparent to the SPA.

I see that in lots of industries - finance, health, cloud providers

While someone will always say “but this doesn’t solve the XSS problem” -
this is absolutely correct. But when there are no tokens in the browser -
you can simply eliminate that part of the threat model ;)

———
Dominick Baier

On 17. February 2021 at 18:30:23, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see from the discussion so
far, it doesn’t appear to be trivial- and there might be some
considerations we consider obvious (eg scope escalation) that might not be
super clear otherwise.

In terms of the guidance, just to make sure I get the scope right- that
means that also code+PKCE+rotating RTs in JS would not be acceptable for
your customers?



*From: *Dominick Baier 
*Date: *Wednesday, February 17, 2021 at 00:27
*To: *Brian Campbell , Torsten Lodderstedt <
tors...@lodderstedt.net>
*Cc: *Vittorio Bertocci , "oauth@ietf.org" <
oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
For Frontend (TMI BFF)



Hey,



Tbh - I have a bit of a hard time to see why this requires a spec, if that
is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
for web apps BCP?”.



All I can add here is - this approach would not work for any of our
customer. Because their real motivation is to implement a more and more
common security guideline these days - namely: “no JS-accessible tokens in
the browser” - but this document doesn’t cover this.



cheers

———

Dominick Baier



On 16. February 2021 at 22:01:37, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:







On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the
draft.



We did attempt to capture the assumptions in the draft but clearly could
have done a better job with it :)




As I understand it now the core contribution of your proposal is to move
refresh token management from frontend to backend. Is that correct?



 Taking that a bit further - the idea is that the backend takes on the
responsibilities of being a confidential client (client creds, token
acquisition, token management/persistence, etc.) to the external AS(s). And
TMI BFF describes a way for that backend to deliver access tokens to its
own frontend.


*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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Hey,

Tbh - I have a bit of a hard time to see why this requires a spec, if that
is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
for web apps BCP?”.

All I can add here is - this approach would not work for any of our
customer. Because their real motivation is to implement a more and more
common security guideline these days - namely: “no JS-accessible tokens in
the browser” - but this document doesn’t cover this.

cheers
———
Dominick Baier

On 16. February 2021 at 22:01:37, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:




On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
wrote:

> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>

We did attempt to capture the assumptions in the draft but clearly could
have done a better job with it :)


>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>

 Taking that a bit further - the idea is that the backend takes on the
responsibilities of being a confidential client (client creds, token
acquisition, token management/persistence, etc.) to the external AS(s). And
TMI BFF describes a way for that backend to deliver access tokens to its
own frontend.

*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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Hi,

Just making sure I understand - in your protocol flow diagram step D it
looks like that the BFF is returning the access token to the front-end. Is
that correct?

My biggest concern with browser-based applications is that the JavaScript /
browser has access to the access token (don’t care if it is in-memory or
local storage) - but this exactly seems to happen in D.

Thanks
———
Dominick Baier

On 12. February 2021 at 21:46:20, Vittorio Bertocci (
vittorio.bertocci=40auth0@dmarc.ietf.org) wrote:

Dear all,
Brian and yours truly are proposing a new specification that shows how the
user agent frontend of a web app can delegate token acquisition and
persistence to its backend, and request such tokens when needed for direct
access of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern
development stacks, such as Next.JS. Variants of the pattern, often
discussed under the catch-all term BFF (backend for frontend), have been
often mentioned in this workgroup’s activity, but always left all
implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption.
By delegating access token acquisition to the backend, we avoid many of the
often brittle moving parts (and implied attack surface) required to acquire
access tokens from a user agent. The topology also relieves the frontend
from the need of persisting tokens in local storage, a well known sore
point of using OAuth directly in JavaScript, by relying on its backend
storage and session to preserve tokens.

Although the specification is very simple, providing explicit guidance on
the scenario offers many advantages.
- It makes it possible to create interoperable SDKs, where frontend dev
stacks (any JS flavor) can be mixed and matched with compliant backend
stacks (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario
and warn implementers against security risks (scope escalations, using
IDtokens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as
part of the browser apps security guidance, and position the scenario where
frontend only calls API on its own backed (hence doesn’t need access
tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly
preventing developers from weakening the security of their system (eg
turning on ROPG options) or turning to risky practices like scraping

Needless to say, this specification doesn’t entirely eliminate the risks
inherent to direct use of access tokens from a browser. But reality is that
the pattern is in widespread use, and the circumstances leading to that (eg
developers on a particular project only work with frontend stacks;
components like reverse proxies might not always be viable; etc) aren’t
going away any time soon. By providing simple guidance on this pattern, we
can simplify the life of many developers while enshrining basic security
hygiene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V

On 2/12/21, 12:41, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to the
IETF repository.

Name: draft-bertocci-oauth2-tmi-bff
Revision: 00
Title: Token Mediating and session Information Backend For Frontend
Document date: 2021-02-12
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt
Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


Abstract:
This document describes how a JavaScript frontend can delegate access
token acquisition to a backend component. In so doing, the frontend
can access resource servers directly without taking on the burden of
communicating with the authorization server, persisting tokens, and
performing operations that are fraught with security challenges when
executed in a user agent, but are safe and well proven when executed
by a confidential client running on a backend.




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.

The IETF Secretariat



___
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] Call for Adoption - AS Issuer Identifier in Authorization Response

[Dominick Baier]

+1

———
Dominick Baier

On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (rifaat.s.i...@gmail.com)
wrote:

All,

This is a call for adoption for the following AS Issuer Identifier in
Authorization Response as a WG document:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

Please, provide your feedback on the mailing list by Dec 22nd.

Regards,
 Rifaat & Hannes
___
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] Implementation Status of "JWT Secured Authorization Request (JAR)"

[Dominick Baier]

Also IdentityServer implements JAR

https://github.com/IdentityServer

———
Dominick Baier

On 21. September 2020 at 21:22:17, Hannes Tschofenig (
hannes.tschofe...@arm.com) wrote:

Hi all



Because some procedural issues I have to update the shepherd writeup of the
JAR document and I wanted to verify whether the implementations listed in
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JAR.txt
(copied below) are still inline with the latest version of
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30 (given the changes
the document has gone through*).



- List of implementations -



As part of the OpenID Foundation certification program the following



implementations of OpenID Connect Core indicate support for this



functionality:



* CZ.NIC mojeID,



* Thierry Habart's SimpleIdentitySever v.2.0.0,



* Roland Hedberg's pyoidc 0.7.7,



* Peercraft ApS's Peercarft,



* MIT's MITREidConnect,



* Gluue Server 2.3,



* Filip Skokan's node-oidc pre supports.





Authlete (https://www.authlete.com/), a commerical, closed source



server implementation, has also implemented this specification and



is offering it.





There is an open source implementation from NRI in PHP and Scala.



NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc



-



Ciao

Hannes



PS: List of changes from the current draft to the one when I wrote my
shepherd writeup:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-09.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt


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

Re: [OAUTH-WG] Shepherd writeup for the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens -- Information about Implementations

[Dominick Baier]

IdentityServer is.

https://github.com/IdentityServer

Cheers
———
Dominick Baier

On 17. September 2020 at 14:56:01, Hannes Tschofenig (
hannes.tschofe...@arm.com) wrote:

Hi Vittorio, Hi all,

I am working on the shepherd writeup for
 and you can find the latest version
here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JWT-Profile-for-AccessTokens.txt

I am in need for information about implementations that are conformant to
this specification. This information would be listed in this write-up, as
background information to the IESG.

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

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Dominick Baier]

Good point. Thanks, Brian.

We should retrofit typs everywhere..in hindsight.

———
Dominick Baier

On 22. July 2020 at 23:55:20, Brian Campbell (bcampb...@pingidentity.com)
wrote:

Because it wouldn't actually prevent it in this case due to JWT assertion
client authentication (a.k.a. private_key_jwt) having come about well
before the JWT BCP and the established concept of using the 'typ' header to
prevent cross-JWT confusion. Thus there's no validation rule regarding the
'typ' header defined in RFC 7523 for JWT client authentication. Explicitly
typing the request object JWT doesn't do anything to prevent it from being
used in the context of previously existing JWT applications like client
auth.

On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier 
wrote:

> Why not use a typ header as suggested by the JWT BCP?
>
> ———
> Dominick Baier
>
> On 22. July 2020 at 17:37:41, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
> The TL;DR here is a somewhat tentative suggestion that a brief security
> consideration be added to
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> <https://datatracker..ietf.org/doc/draft-ietf-oauth-jwsreq/> that
> prohibits the inclusion of a 'sub' claim containing the client id value in
> the request object JWT so as to prevent the request object JWT (which is
> exposed to the user agent) from being erroneously accepted as a valid JWT
> for client authentication.
>
> Some more details and the discussion that led to this here email can be
> found at https://github.com/oauthstuff/draft-oauth-par/issues/41
>
> *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
>
>
*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

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Dominick Baier]

Even more. Jwsreq should have it. But the authors decided against it.

———
Dominick Baier

On 23. July 2020 at 07:38:04, Dominick Baier (dba...@leastprivilege.com)
wrote:

Good point. Thanks, Brian.

We should retrofit typs everywhere..in hindsight.

———
Dominick Baier

On 22. July 2020 at 23:55:20, Brian Campbell (bcampb...@pingidentity.com)
wrote:

Because it wouldn't actually prevent it in this case due to JWT assertion
client authentication (a.k.a. private_key_jwt) having come about well
before the JWT BCP and the established concept of using the 'typ' header to
prevent cross-JWT confusion. Thus there's no validation rule regarding the
'typ' header defined in RFC 7523 for JWT client authentication. Explicitly
typing the request object JWT doesn't do anything to prevent it from being
used in the context of previously existing JWT applications like client
auth.

On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier 
wrote:

> Why not use a typ header as suggested by the JWT BCP?
>
> ———
> Dominick Baier
>
> On 22. July 2020 at 17:37:41, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
> The TL;DR here is a somewhat tentative suggestion that a brief security
> consideration be added to
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> <https://datatracker..ietf.org/doc/draft-ietf-oauth-jwsreq/> that
> prohibits the inclusion of a 'sub' claim containing the client id value in
> the request object JWT so as to prevent the request object JWT (which is
> exposed to the user agent) from being erroneously accepted as a valid JWT
> for client authentication.
>
> Some more details and the discussion that led to this here email can be
> found at https://github.com/oauthstuff/draft-oauth-par/issues/41
>
> *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
>
>
*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

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Dominick Baier]

Why not use a typ header as suggested by the JWT BCP?

———
Dominick Baier

On 22. July 2020 at 17:37:41, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:

The TL;DR here is a somewhat tentative suggestion that a brief security
consideration be added to
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
<https://datatracker..ietf.org/doc/draft-ietf-oauth-jwsreq/> that prohibits
the inclusion of a 'sub' claim containing the client id value in the
request object JWT so as to prevent the request object JWT (which is
exposed to the user agent) from being erroneously accepted as a valid JWT
for client authentication.

Some more details and the discussion that led to this here email can be
found at https://github.com/oauthstuff/draft-oauth-par/issues/41

*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

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

[Dominick Baier]

I support adoption

———
Dominick Baier

On 16. July 2020 at 01:54:08, William Denniss (
wdenniss=40google@dmarc.ietf.org) wrote:

I support adoption.

On Wed, Jul 15, 2020 at 4:37 PM  wrote:

> +1
>
>
>
> *From:* OAuth  *On Behalf Of *Dick Hardt
> *Sent:* Wednesday, July 15, 2020 10:55 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document
>
>
>
> +1
>
>
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
>
>
> This is a *call for adoption* for the following *OAuth 2.1* document as a
> WG document:
>
> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>
>
>
> Please, provide your feedback on the mailing list by *July 29th.*
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> ___
> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation...

[Dominick Baier]

Hey,

Have a look at https://github.com/IdentityServer/IdentityServer4

<https://github.com/IdentityServer/IdentityServer4>
I <https://github.com/IdentityServer/IdentityServer4>t’s an OIDC certified
..NET implementation

Thanks!
———
Dominick Baier

On 25. June 2020 at 11:27:34, Thibault Normand (thibault.norm...@gmail.com)
wrote:

Hello Pieter,

I'm also interested (https://github.com/zntrio/solid), my OIDC framework is
not focused on building a compliant OIDC server but produce a restricted
and harmonized feature set according to your authentication use cases
(human, act as human, software, machine, iot). It mostly like libsodium is
(a high-level api) for low-level encryption operations (CHACHA20/Poly130).

The project is quite new and focused on authorization server building
blocks without the wire protocol constraints.
I tried to design flow without the wire protocol constraints in order to
make the building blocks useable in different context (standard / HTTP, or
IoT / CoAP).

Regards,

Le lun. 22 juin 2020 à 17:25, Filip Skokan  a écrit :

> Hello Pieter,
>
> I’m interested for my open source project.
>
> Filip
>
> Odesláno z iPhonu
>
> 22. 6. 2020 v 15:51, Pieter Philippaerts  >:
>
> 
> Hello everyone,
>
> As part of a research project, I've created a test suite to test OAuth 2.0
> implementations and measure how well they implement the various
> MAY/SHOULD/MUST security recommendations in the OAuth standards. (It also
> includes test cases for the OIDC and FAPI RO/RW recommendations.) The tool
> is practically finished and will be made available to the public in a few
> months.
>
> I'm currently working on a security analysis of the OAuth2 ecosystem
> (i..e. I'm using the tool to test various OAuth/OIDC implementations) and
> I'm still looking for more candidates to test. If you are the author of an
> OAuth library or if you are running an OAuth service, feel free to contact
> me to get involved. Apart from my gratitude, I can offer you a free
> security audit of your product :-)
>
> Regards,
> Pieter
>
>
> ___
> 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
>


-- 
Thibault Normand
"Il existe moins bien mais c'est plus cher !"
http://www.zenithar.org
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] To the authors of jwsreq/JAR

[Dominick Baier]

Hi,

We had asked a couple of questions over the last weeks regarding details of
the JAR spec. Not a single response from the spec authors.

We are in the process of implementing JAR and about to release the software..

We need some clarifications and I am confused that we did not get any
response. Is it a technical issue?

thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JAR: JWT typ

[Dominick Baier]

Hi,

This has been brought up before - but no response.

Either I can’t find it - or it is missing. But is the setting the JWT typ
explicitly mentioned somewhere?

I think it should to prevent cross JWT confusion.

Thanks
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-jwsreq-21

[Dominick Baier]

Would be also interested in the official language here.

Would an implementation need to introduce an optional  “strict JAR
validation mode”  - which complies with JAR, but breaks OIDC compatibility?

———
Dominick Baier

On 7. May 2020 at 15:32:33, Brock Allen (brockal...@gmail.com) wrote:

Perhaps quite late, but a few comments/questions related to this:

1) When decoded, all the JWT samples are missing the "typ" claim from the
header, which I think should be "oauth.authz.req+jwt".

2) When validating the JAR if we are to validate the "typ" then this would
be incompatible with OIDC's request object, I think?

3) When the JAR is passed by reference, then the HTTP response Content-Type
of "application/oauth.authz.req+jwt" would also seem to break or be
incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this w/ an OIDC OP
implementation.

TIA

-Brock

___
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 2.1 - require PKCE?

[Dominick Baier]

In IdentityServer, the PKCE requirement is per client.

We started with a default of false - and now switched to true.

FWIW
———
Dominick Baier

On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:

Exactly!



I believe that this also the same point that Brian Campbell was making
earlier about interoperability implications.



   -- Mike



*From:* Neil Madden 
*Sent:* Sunday, May 10, 2020 1:06 PM
*To:* Dick Hardt 
*Cc:* Mike Jones ; oauth@ietf.org; Torsten
Lodderstedt 
*Subject:* Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?



But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
requests that don’t include a code_challenge (section 4.1.2.1), so this
will only be possible when all clients support PKCE.



This makes it impossible for a 2.1-compliant AS to also support non-PKCE
2.0 clients (i.e., the vast majority of them).



I think we can have a 2.1 spec that says clients and servers MUST support
PKCE without this hard-fail clause. Otherwise I can’t see how we’d ever
ship with 2.1-compliance enabled out-of-the-box.



— Neil



On 10 May 2020, at 20:38, Dick Hardt  wrote:



Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as
the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth
2.0 was voluntary.



Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?





On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:

I agree with actively maintaining and improving the OAuth 2.0 specs by
adding enhancements that are voluntary to use.  I’ve worked on many such
improvements, including Dynamic Client Registration, Authorization
Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
etc.  The issue that’s the subject is the current discussion is whether to
make use of another enhancement, PKCE, mandatory in cases where it’s
actually not needed, rather than making its use voluntary like the other
enhancements, which I certainly support.



   -- Mike



*From:* Torsten Lodderstedt 
*Sent:* Sunday, May 10, 2020 3:15 AM
*To:* Mike Jones 
*Cc:* Daniel Fett ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



Hi Mike,



Mike Jones  schrieb am Fr. 8.
Mai 2020 um 18:55:

OAuth 2.1 was supposed to not introduce breaking changes.

I cannot remember the WG met that decision. Can you please refer to the
respective thread?



Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?





If you want to do that, please do it in TxAuth instead.



Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.



I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That’s better protection of
existing investments than sending them of to TXAuth.

Kind regards,

Torsten.





   -- Mike



*From:* OAuth  *On Behalf Of *Daniel Fett
*Sent:* Thursday, May 7, 2020 11:50 PM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE?



+1 to all what Aaron said. Thanks for pointing this out!



We need to address this in the security BCP and this will be a normative
change that affects OpenID Connect Core (just as our current recommendation
on the usage of nonce).



We would then have:



- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE,
except if you are a public client, then you still need PKCE.

- use state, except if you use PKCE, then you don't need state.



I think there are very good reasons to simplify this down to



- use PKCE

- you may or may not use state



First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding *why* you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it is
not needed, but its better to use it all the time" is easy to understand.
We will not see many implementations following the long version above
correctly.



Second, we dramatically reduce technical complexity by reducing cases that
need to be handled. We reduce correctness and compliance testing complexity
in the same way. We reduce the cost of security analysis, which scales
really badly to more cases.



And finally, using nonce to protect against code injection is less robust
than PKCE. AS have a better track record than clients when it comes to
correctly implementing security mechanisms.



Yes, this will make a number of implementations non

Re: [OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Oh - and last thing I forgot to mention.

We had the luxury of designing IdentityServer from the ground up after OIDC
has been released. So it really was fine tuned to be a OIDC + OAuth
implementation. Hence the strong semantics of the sub claim for both the
OIDC and OAuth parts. We think this is right because all of our customers
use both in conjunction.

IOW - you move our cheese ;) But don’t worry about it.

———
Dominick Baier

On 4. May 2020 at 10:55:41, Dominick Baier (dba...@leastprivilege.com)
wrote:

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a “off the shelf” product or SaaS - it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something “dangerous” - e.g.we cannot enforce how subs or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: “if there is a sub - a user is involved, if not - then not”.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519”.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;)


Still some comment inline...


thanks
———
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.berto...@auth0.com)
wrote:

Thank you Dominick, very useful!

I’d like to understand more about the security risks you mention. My goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don’t particularly
care about token size or you don’t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn’t correspond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant… the main way I can see this going south would be if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub = user ID. OIDC scopes = what data is returned. This
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That’s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they’d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven’t studied the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren’t necessarily human; and I remember one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don’t have to, if the user can set arbitrary
values they can already do things that would break standard

Re: [OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a “off the shelf” product or SaaS - it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something “dangerous” - e.g.we cannot enforce how subs or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: “if there is a sub - a user is involved, if not - then not”.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519”.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;)


Still some comment inline...


thanks
———
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.berto...@auth0.com)
wrote:

Thank you Dominick, very useful!

I’d like to understand more about the security risks you mention. My goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don’t particularly
care about token size or you don’t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn’t correspond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant… the main way I can see this going south would be if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub = user ID. OIDC scopes = what data is returned. This
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That’s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they’d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven’t studied the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren’t necessarily human; and I remember one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don’t have to, if the user can set arbitrary
values they can already do things that would break standards (like
assigning the same sub to two different users) hence in that case you can’t
be responsible for it at product design, it’s kind of up to them.



Note, I know that answering the above might require extra work in
investigating and writing about it, I don’t mean to burden you with it. My
aim here is understanding whether the challenges you identified mostly stem
from the underlying assumption “presence of a sub=>it’s a user”, which is
understandable but was established in the discussions referenced ab

[OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Hey,

Just some notes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that’s very useful
* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that’s the reason AAD emits
it as well)
* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that’s how the claims
plumbing in .NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can “force” an audience even for this situation if you
absolutely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.

I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs

* the user info endpoint needs to do extra checking
* extension grants that did not use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id

This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the “dual
purpose” claims are the best choice. YMMV.

IOW - we will not adopt the sub/client_id semantics as proposed by the
document.


My 2c / cheers
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

Oh and while we are at it - could you also fix the typo in my name? Thanks
;)

———
Dominick Baier

On 21. April 2020 at 09:43:49, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:

This is a great point. In my head I just considered the OIDC semantic and
thought only of highlighting the app identity case, but you are absolutely
right that not mentioning the user case at all is confusing. I added the
language you suggested at the beginning of the sub definition.

Thanks!



*From: *Dominick Baier 
*Date: *Monday, April 20, 2020 at 22:54
*To: *oauth , Rifaat Shekh-Yusef , "
vittorio.berto...@auth0.com" 
*Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"



In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.



Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?



There’s some language that seems to imply that, e.g.:



as this would allow malicious

   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -



In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.



If this spec is about interop, I think this should be at least a
recommendation...





———

Dominick Baier



On 20. April 2020 at 09:48:51, vittorio.berto...@auth0.com (
vittorio.berto...@auth0.com) wrote:

Thanks Dominick for your comments!

Inline



*>** All other OAuth specs make a very clear distinction between users and
client.*

There’s a nuance worth highlighting here: sub != user. In previous
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that’s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, “In case of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.“ and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.



*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.



*>** I am not fully clear why aud is required.*

Aud is there mostly because of three reasons:

· Many existing specs postulate its existence in the token. No one
declares it as a proper MUST (apart from the BCP, but that’s partial)
however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the
mechanism to prevent token redirect (and adds scope restriction as also
important, however here we make it optional to acocut for non-delegations
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one
of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one
app

· Apart from Ping, for which some of its examples are without aud
(but also without identifying scopes, given that the one I retrieved had
only “openid”), all of the sample JWT ATs I received from vendors all
featured an aud. I know one shoulnd’t overindex on those examples, but
together with the above it seemed to point to something universally useful.
One possible reason is that use of a format for the AT is correlated with
topologies where AS and RS are separated by some boundary (network,
logical, business, code factoring, etc) hence identifying the resource
seems like a natural need. Again, not an iron clad law, but an indication.

· A lot of people repurpose existing libraries for the JWT AT case,
and some people even sends id_tokens in lieu of ATs. That doesn’t mean that
we should condone any bad practices, but in tis particular case it suggests
that lots of developers already expect/can handle an audience in the JWT
used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
th

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.


Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?

There’s some language that seems to imply that, e.g.:

as this would allow malicious
   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -

In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.


If this spec is about interop, I think this should be at least a
recommendation...


———
Dominick Baier

On 20. April 2020 at 09:48:51, vittorio.berto...@auth0.com (
vittorio.berto...@auth0.com) wrote:

Thanks Dominick for your comments!

Inline



*>** All other OAuth specs make a very clear distinction between users and
client.*

There’s a nuance worth highlighting here: sub != user. In previous
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that’s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, “In case of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.“ and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.



*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.



*>** I am not fully clear why aud is required.*

Aud is there mostly because of three reasons:

   - Many existing specs postulate its existence in the token. No one
   declares it as a proper MUST (apart from the BCP, but that’s partial)
   however I think its importance comes across..
   -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
   mechanism to prevent token redirect (and adds scope restriction as also
   important, however here we make it optional to acocut for non-delegations
   scenario).
   -Resource indicators RFC8707 refers to the same section of RFC7519 as
   one of the assumptions that must hold to prevent bearer tokens misuse
   -BCP225 makes aud mandatory for AS which can issue JWTs for more than
   one app
   - Apart from Ping, for which some of its examples are without aud (but
   also without identifying scopes, given that the one I retrieved had only
   “openid”), all of the sample JWT ATs I received from vendors all featured
   an aud. I know one shoulnd’t overindex on those examples, but together with
   the above it seemed to point to something universally useful. One possible
   reason is that use of a format for the AT is correlated with topologies
   where AS and RS are separated by some boundary (network, logical, business,
   code factoring, etc) hence identifying the resource seems like a natural
   need. Again, not an iron clad law, but an indication.
   - A lot of people repurpose existing libraries for the JWT AT case, and
   some people even sends id_tokens in lieu of ATs. That doesn’t mean that we
   should condone any bad practices, but in tis particular case it suggests
   that lots of developers already expect/can handle an audience in the JWT
   used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
the presence of scopes or other disambiguation. One reason I feel pretty
good about that is that adding a default audience isn’t very hard if any of
the above assumptions end up not being true for a particular case



*> What’s the rationale for using iat instead of nbf. *

That’s just straight from OIDC ID_tokens, and the considerations about
repurposing existing logic. I see there’s a thread on this specifically,
let me answer further on that branch.



*> This spec feels somehow in between a profile and a BCP*

You are right that this spec attempts to go beyond just declaring a layout,
and I agree this means that this profile will not apply to absolutely
everyone. The reason I tried that route 

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

Hence my question

What should be the recommended semantics - “informative” - “or don’t accept
before a certain time stamp” ?

———
Dominick Baier

On 20. April 2020 at 09:05:53, Philippe De Ryck (
phili...@pragmaticwebsecurity.com) wrote:

In theory, you can issue a token that only becomes valid in the future.
That would have a different iat and nbf timestamp. I have not seen this in
practice though.

Given that RFC 7519 lists “iat” as informative, I would not change that
behavior in a specific use case if there is no significant need to do so.

Philippe

On 20 Apr 2020, at 08:50, Dominick Baier  wrote:

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what’s the difference between the two
practically speaking - and shouldn’t be the more common (aka supported by
most libraries) be used?

———
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=40alkaline-solutions@dmarc.ietf.org) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret “iat" to also have the meaning of “nbf”
in the absence of “nbf”, although this is AFAIK not prescribed by any spec
2. The DPoP draft’s client-generated tokens have the resource servers use
their own nbf/exp heuristics around “iat”, since the tokens are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an “iat” too far in the past or “exp” too far in the
future, but not that “nbf” was too far in the past or that the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov 
wrote:

On 16/04/2020 10:10, Dominick Baier wrote:

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the ..NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir
___
OAuth mailing list
oa...@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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what’s the difference between the two
practically speaking - and shouldn’t be the more common (aka supported by
most libraries) be used?

———
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=40alkaline-solutions@dmarc.ietf.org) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret “iat" to also have the meaning of “nbf”
in the absence of “nbf”, although this is AFAIK not prescribed by any spec
2. The DPoP draft’s client-generated tokens have the resource servers use
their own nbf/exp heuristics around “iat”, since the tokens are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an “iat” too far in the past or “exp” too far in the
future, but not that “nbf” was too far in the past or that the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov 
wrote:

On 16/04/2020 10:10, Dominick Baier wrote:

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the ..NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir
___
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] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.

*client_id vs sub*
I am still not entirely happy with the “re-purposing” of the claim types
based on flow.
If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and
client.

Furthermore it says

"Authorization servers should prevent scenarios where clients can
   affect the value of the sub claim in ways that could confuse resource
   servers.”

If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.

Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.

*audience claim*
I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don’t exist, you'd need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What’s the
value of that?

If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn’t make it required.

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the .NET one) looking for nbf by default?

*General*
This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn’t work
one way or the other for them.

I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the
“at+jwt” typ. For the rest I’d rather like to see just some standard claims
and IF they are used, which semantics they have.

cheers
———
Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.i...@gmail.com)
wrote:

Hi all,



This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



Please send your comments to the OAuth mailing list by April 29, 2020.



Regards,

 Rifaat & Hannes


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

[OAUTH-WG] Full Third-Party Cookie Blocking

[Dominick Baier]

This

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

Really means that “modern” SPAs based on a combination of OIDC and OAuth
will not work anymore

both

* silent-renew for access token management
* OIDC JS session notifications

Will not work anymore. Or don’t work anymore already today - e.g. in Brave.

This means SPAs would need to be forced to do refresh tokens - and there is
no solution right now for session notifications.

Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the
“browser apps without a back-end” scenario and promote the BFF style
architecture instead.

Cheers
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: DPoP

[Dominick Baier]

+1

———
Dominick Baier

On 17. March 2020 at 14:18:37, Torsten Lodderstedt (
torsten=40lodderstedt@dmarc.ietf.org) wrote:

+1

> On 17. Mar 2020, at 13:40, Vladimir Dzhuvinov 
wrote:
>
> +1 for DPoP
>
> On 17/03/2020 14:25, Rob Otto wrote:
>> I support adoption
>>
>> Thank you
>> Rob Otto
>>
>> On Tue, 17 Mar 2020 at 12:21, Rifaat Shekh-Yusef 
wrote:
>> All,
>>
>> As per the conclusion of the PoP interim meeting, this is a call for
adoption for the OAuth 2.0 Demonstration of Proof-of-Possession at the
Application Layer (DPoP) document:
>> https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
>>
>> Please, let us know if you support or object to the adoption of this
document as a working group document by March 31st.
>>
>> Regards,
>> Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> --
>>
>> Rob Otto
>> EMEA Field CTO/Solutions Architect
>> roberto...@pingidentity.com
>>
>> c: +44 (0) 777 135 6092
>> Connect with us:
>>
>>
>> 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
> --
> Vladimir Dzhuvinov
>
> ___
> 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] First Draft of OAuth 2.1

[Dominick Baier]

Off the top of my head, rotation is useful for 2 things

* reducing the likelihood that an “old” refresh token is still valid (e.g.
“found” on some device, log file, source code etc...)
* being able to revoke all the active refresh tokens if a refresh token is
used twice

...and yes it introduces a higher chance of false positives.

https://leastprivilege.com/2020/01/21/hardening-refresh-tokens/

But I agree with the spec - if the refresh token cannot be bound to a
client by a secret (looking at you, SPAs) - it should be hardened using
sliding expiration, rotation and replay detection. Maybe the wording needs
to be clearer.

———
Dominick Baier

On 12. March 2020 at 23:15:19, Vittorio Bertocci (
vittorio=40auth0@dmarc.ietf.org) wrote:

Rotation can be used to detect leakage, right? Client credentials offer
more guarantees, but unless you are using private JWTs with a non
exportable certificate as client cred, a classic client secret _could_
technically leak. Having rotation would alert you if someone got a hold on
those. Admittedly it’s a stretch, but not entirely inconceivable.

On Thu, Mar 12, 2020 at 13:57 Torsten Lodderstedt  wrote:

> Then why are you rotating refresh tokens?
>
> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva  >:
>
> 
> A confidential client, as per the `web application` definition in Section
> `2.1.  Client Types`.
>
> On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Is that a public client?
>>
>> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva :
>>
>> 
>> I agree with you and recently, we had to deal with an issue where a `web
>> application` using rotation (as defined by the draft) was having issues to
>> refresh tokens due to multiple concurrent requests at the moment a token is
>> about to expire or already expired.. We had to add some controls to deal
>> with concurrency and additional complexity + performance penalties. And for
>> such clients, I was not sure whether or not rotation makes sense.
>>
>>
>> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>>> Thanks for the clarification, Torsten.
>>> I believe it's the first time I see use of client credentials positioned
>>> as sender constraint; if the intent is saying that confidential clients
>>> should use their credentials when redeeming refresh tokens, I am of course
>>> in agreement but I think the language should be clearer and state the above
>>> explicitly.
>>>
>>> Re: failure frequency, I know of scenarios were the designers added
>>> rotation by default, and after a while it was turned to opt in because of
>>> the frequency of errors and impact on user experience/call center.
>>> I really believe that putting this as a MUST is justified only for
>>> exceedingly vulnerable situations, like SPAs.
>>> Native/desktop clients should be free to decide whether they want to opt
>>> in without loosing compliance. Just my 2 C
>>>
>>> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt >> 40lodderstedt@dmarc.ietf.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> sender constraining refresh tokens for confidential client means client
>>>> authentication + check the binding of the refresh token with the respective
>>>> client id. I don’t think this is new as RFC6759 already required ASs to
>>>> check this binding. Assuming backends are generally confidential clients
>>>> also means no rotation and no cache synchronization needed.
>>>>
>>>> Rotation should be used for frontends, e.g. native apps and only if
>>>> there is there no other option. If a refresh fails, the app must go through
>>>> the authorization process again. That’s inconvenient so the question is how
>>>> often this happens. What I can say, I have never seen customer complaining
>>>> in several years of operation of ASs with refresh token rotation (including
>>>> replay detection) for native apps with millions of users.
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci >>> 40auth0@dmarc.ietf..org <40auth0@dmarc.ietf.org>>:
>>>>
>>>> 
>>>> Hey guys,
>>>> thanks for putting this together.
>>>> I am concerned with the real world impact of imposing sender
>>>> constraint | rotation as a MUST on refresh tokens in every scenario.
>>>> Sender constraint isn't immediately actionable - we just had the
>>

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[Dominick Baier]

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

IMHO - if such a thing gets defined, it should be a separate document. Keep
2.1 as simple as possible.

———
Dominick Baier

On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:

It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

With the goal of OAuth 2.1 being a capture of all the best practices, (2)
makes more sense as it could discuss all aspects of service accounts
including mapping a client to a service account.

What do others think?


ᐧ

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:

> Let us do it then and deprecate ROPC.
> There definitely are use-cases that need this pattern around me as well,
> but we are using JWT bearer grant instead. Standardizing the behavior is
> good. I am fine with new service_account grant type as well, btw.
>
> Nat
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> I’d be open to defining a new service_account grant type and
> removing/deprecating the ROPC grant. I’d also be happy if we just said that
> service account flows should use the JWT bearer grant, and we document the
> best practices around that and encourage client libs to implement support
> for it.
>
> Should there be a dedicated draft for best practices for
> service-to-service usage?
>
> — Neil
>
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I 100% agree that the job of a standard is not to tell people "what they
> ought to be doing". Instead, a standard is more about documenting the
> current state of the art as deployed in existing implementations.
>
> With that in mind, I think that leaves us with two concrete problems with
> the password grant:
>
> 1) The actual problem with the password grant is end users entering
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service
> accounts or backends that are inflexible, not actually using it for end
> user credentials
>
> So it seems like there's actually something missing from OAuth which is
> leading people to find the password grant and use that because it's the
> only thing that most closely fits their existing model. It seems like we'd
> be better off defining a new extension that captures the use case people
> are actually doing, instead of encouraging the continuing use of the
> password grant for this purpose.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> Are we really going to tell them to rewrite it all to use the client
> credentials grant?
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time
> to get rid of it and send people toward what they really ought to be doing.
>
> Anothe

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

[Dominick Baier]

No - please get rid of it.

———
Dominick Baier

On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com) wrote:

Hey List

(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron,
Torsten, and I are working on)

Given the points Aaron brought up in

https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU


Does anyone have concerns with dropping the implicit flow from the OAuth
2.1 document so that developers don't use it?

/Dick
___
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] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Dominick Baier]

Agreed - that’s why we disabled request_uri by default and added
extensibility points to implement validation.

I thought it is odd that this was not mentioned in the typical “security
considerations” in the OIDC spec..

———
Dominick Baier

On 16. January 2020 at 08:07:44, Neil Madden (neil.mad...@forgerock.com)
wrote:

If the AS can’t validate the request_uri it may also open itself up to SSRF
attacks where a malicious client uses the request_uri to probe/attack
resources inside the AS’s private network. This was a crucial part of the
recent Capital One breach for example [1].  ForgeRock currently requires
strict validation of request_uris against a client-specific whitelist for
exactly this reason.

NB some clients might legitimately be on that private network (eg
microservices) so changing to a global whitelist for all clients is
undesirable.

[1]: https://ejj.io/blog/capital-one

— Neil

On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov 
wrote:

On 14/01/2020 19:20, Takahiko Kawasaki wrote:

Well, embedding a client_id claim in the JWE header in order to achieve
"request parameters outside the request object should not be referred to"
is like "putting the cart before the horse". Why do we have to avoid using
the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1
<https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says as
follows.

*A client MAY use the "client_id" request parameter to identify itself when
sending requests to the token endpoint.  In the "authorization_code"
"grant_type" request to the token endpoint, an unauthenticated client MUST
send its "client_id" to prevent itself from inadvertently accepting a code
intended for a client with a different "client_id".  This protects the
client from substitution of the authentication code.  (It provides no
additional security for the protected resource.)*


If the same reasoning applies, a client_id must always be sent with request
/ request_uri because client authentication is not performed at the
authorization endpoint. In other words, *an unauthenticated client (every
client is unauthenticated at the authorization endpoint) MUST send its
"client_id" to prevent itself from inadvertently accepting a request object
for a client with a different "client_id".*

Identifying the client in JAR request_uri requests can be really useful so
that an AS which requires request_uri registration to prevent DDoS attacks
and other checks can do those without having to index all request_uris
individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist on
no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't particularly
transparent to WG members.

Vladimir


Best Regards,
Taka



On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
wrote:

> John, thanks, much appreciated!
> On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header.
>
> I will see if i can add something in final edits to call that out.
>
> John B.
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>
> Thanks Mike for the rfc7519 section-5.3
> <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this
> parameter replication be used for client_id or the client_id ass "iss" even
> though it isn't explicitly mentioned in the JAR spec?
> On 11/01/2020 02:58, John Bradley wrote:
>
> Right we just don't say to put the iss there in OIDC if it's symetricly
> encrypted.
>
> OIDC doesn't have the symmetric key selection issue, I suppose that why
> the possibility to replicate params to the JWE header isn't mentioned at
> all. OIDC requires the top-level query params to represent a valid OAuth
> 2.0 request, and there client_id is required. If the client_id is present
> the client registration together with any present client_secret can be
> retrieved.
>
> I reread the JAR spec, this is the only place that mentions handling of
> symmetric JWE.
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>
> (b)  Verifying that the symmetric key for the JWE encryption is the
> correct one if the JWE is using symmetric encryption.
>
>
> Vladimir
>
>
>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  > wrote:
>
>> The technique of replicating JWT claims that need to be publicly visible
>> in an encrypted JWT in the header is defined at
>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
>> for bringing this need to my attention as we were finishing the JWT spec..)
>>
>>
>>
>>-- Mike
>>
>&

Re: [OAUTH-WG] Meeting Minutes

[Dominick Baier]

I’d support adoption of both PAR and RAR.

———
Dominick Baier

On 16. December 2019 at 23:02:58, Rob Otto (
robotto=40pingidentity@dmarc.ietf.org) wrote:

I’d support adoption of both PAR and RAR.

On Mon, 16 Dec 2019 at 21:57, Richard Backman, Annabelle  wrote:

> +1 for a call for adoption on PAR.
>
>
>
> I’d also like to see one for RAR; while there are questions that need to
> be resolved, there seems to be strong interest in this work and adoption
> means we can have those discussions within the WG where they belong.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From:* OAuth  on behalf of Justin Richer <
> jric...@mit.edu>
> *Date:* Monday, December 16, 2019 at 12:36 PM
> *To:* Brian Campbell 
> *Cc:* "oauth@ietf.org" 
> *Subject:* Re: [OAUTH-WG] Meeting Minutes
>
>
>
> +1 to this. My take away was that PAR was pretty clear for adoption right
> now, RAR had interest but more question/debate.
>
>
>
> FWIW I’m in favor of both of them.
>
>
>
>  — Justin
>
>
>
> On Dec 16, 2019, at 11:26 AM, Brian Campbell <
> bcampbell=40pingidentity@dmarc.ietf.org> wrote:
>
>
>
> With respect to the Pushed Authorization Requests (PAR) draft the minutes
> do capture an individual comment that it's a "no brainer to adopt this
> work" but as I recall there was also a hum to gauge the room's interest in
> adoption, which was largely in favor of such. Of course, one hum in
> Singapore isn't the final word but, following from that, I was
> hoping/expecting to see a call for adoption go out to the mailing list?
>
>
>
> On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
> Here are the meeting minutes from the Singapore IETF meeting:
>
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03
>
>
>
> Tony was our scribe. Thanks!
>
>
>
>
>
> 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
>
>
> * 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
>
--
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

* 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

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[Dominick Baier]

My preference would be that if a request object is used, all parameters
must go in there

a) makes the AS implementation easier
b) there is really no point (IMO) to have a mixture of signed and unsigned
parameters
c) certain parameters should go into the RO - e.g. the code_challenge to
prevent the “chosen code challenge attack” (at least that’s how I
understood it) - again enforcing that makes the AS logic more complicated
d) it’s a clear statement

cheers
———
Dominick Baier

On 11. December 2019 at 03:29:14, Nat Sakimura (sakim...@gmail.com) wrote:

Correct. The WG supported the precedence approach and even merge just like
OIDC as it is very useful from the implementation point of view and helps
with a bunch of deployment patter.

The push back came in from the Ben Campbell’s DISCUSS.
See
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the

I am willing to go either way as long as people agree. My slight preference
is to the original approach.

Best,

Nat Sakimura

2019年8月29日(木) 6:56 Brian Campbell >:

> FWIW, as best I can remember the change in question came as I result of 
> directorate/IESG
> review rather than a WG decision/discussion. Which is likely why you can't
> find the "why" anywhere in the mailing list archive.
>
> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan  wrote:
>
>> Well it kind of blows, doesn't it? I wasn't able to find the "why"
>> anywhere in the mailing list archive around the time this was changed.
>>
>> My take on satisfying both worlds looks like this
>>
>> - allow just JAR - no other params when possible.
>> (which btw isn't possible to do with request_uri when enforcing
>> client based uri whitelist and the jwsreq 5.2.2 shows as much)
>> - enforce the "dupe behaviours" defined in OIDC (if response_type or
>> client_id is in request object it must either be missing or the same in
>> regular request).
>> - allows merging request object and regular parameters with request
>> object taking precedence since it is a very useful feature when having
>> pre-signed request object that's not one time use and clients using it wish
>> to vary state/nonce per-request.
>>
>> I wish the group reconsidered making this breaking change from OIDC's
>> take on request objects - allow combination of parameters from the request
>> object with ones from regular parameters (if not present in request object).
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell 
>> wrote:
>>
> Filip, for better or worse, I believe your assessment of the situation is
>>> correct. I know of one AS that didn't choose which of the two to follow but
>>> rather implemented a bit of a hybrid where it basically ignores everything
>>> outside of the request object per JAR but also checks for and enforces the
>>> presence and value of the few regular parameters (client_id, response_type)
>>> that OIDC mandates.
>>>
>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> in an earlier thread I've posed the following question that might have
>>>> gotten missed, this might have consequences for the existing
>>>> implementations of Request Objects in OIDC implementations - its making
>>>> pure JAR requests incompatible with OIDC Core implementations.
>>>>
>>>> draft 14 of jwsreq (JAR) introduced this language
>>>>
>>>> The client MAY send the parameters included in the request object
>>>>> duplicated in the query parameters as well for the backward
>>>>> compatibility etc.
>>>>>
>>>>> *However, the authorization server supporting this specification MUST
>>>>> only use the parameters included in the request object. *
>>>>
>>>>
>>>> Server MUST only use the parameters in the Request Object even if the
>>>>> same parameter is provided in the query parameter.  The Authorization
>>>>
>>>>
>>>> The client MAY send the parameters included in the request object
>>>>> duplicated in the query parameters as well for the backward
>>>>> compatibility etc.
>>>>>
>>>>> *However, the authorization server supporting this specification MUST
>>>>> only use the parameters included in the request object. *
>>>>
>>>>
>>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores
>>>> everything outsi

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Dominick Baier]

August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick

On 25. July 2019 at 22:14:28, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:

I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-Original Message-
From: OAuth  On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll
be easier/cheaper to bundle the two trips into one. (Hopefully we could get
the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt  wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth
Security Workshop in Trondheim, Norway. We will therefore start with the
planning.
>>
>> After checking various event calendars it seems like the following dates
are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The
latter two dates are before/after IETF 108 which is July 25-31,
Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting
identity/security events we will pick one of these dates in the next two
weeks or so.
>>
>> -Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
___
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] Feedback on OAuth for browser-based Apps

[Dominick Baier]

To clarify.

Using CSP is a general best practice for every JS app.

Once tokens are stored in the browser you want to specifically focus on
injection attacks (XSS) - disabling inline scripting is key to that.

———
Dominick

On 24. July 2019 at 23:04:20, Aaron Parecki (aa...@parecki.com) wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:

> I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.

I agree, I removed the mention of OIDC.

> I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if refresh or
access tokens are involved - further settings like disabling inline
scripting (unsafe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?


Aaron Parecki
aaronparecki.com
@aaronpk



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:
>
> Hey,
>
> Just read the spec - good to see the progress. Some feedback:
>
> I am yet undecided if I like the categorisation of the “Application
Architecture Patterns”. I definitely want to distinguish between
applications only accessing same-site back-end services and “others”. Not
sure if “dynamic application server" and “static application server” should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don’t have
the right answer wrt to categories right now.
>
> 6.1. Apps Served from a Common Domain as the Resource Server
>
> > OAuth and OpenID Connect provide very little benefit in this
> deployment scenario, so it is recommended to reconsider whether you
> need OAuth or OpenID Connect at all in this case.
>
> I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.
>
>
> 6.2. Apps Served from a Dynamic Application Server
>
> I have a .NET sample for that
>
>
https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
> And a blog post
>
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>
> 9.7. Content-Security Policy
>
> A browser-based application that wishes to use either long-lived
> refresh tokens or privileged scopes SHOULD restrict its JavaScript
> execution to a set of statically hosted scripts via a Content
> Security Policy ([CSP2]) or similar mechanism.
>
>
>
> I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if refresh or
access tokens are involved - further settings like disabling inline
scripting (unsafe inline) and eval should be disabled.
>
> Thanks for doing this work!
>
> ———
> Dominick
> ___
> 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] Feedback on OAuth for browser-based Apps

[Dominick Baier]

Yes it would.

———
Dominick

On 23. July 2019 at 10:08:43, Filip Skokan (panva...@gmail.com) wrote:

Wouldn’t that contradict the security topics BCP?

Odesláno z iPhonu

23. 7. 2019 v 9:44, Neil Madden :

Technically it could be optional, but it means that a CSRF attempt will
only be detected by the AS not by the client. If we consider the
possibility of a malicious AS, then this could allow Login CSRF attacks
against the client. The client would also have to be sure that the AS
actually implements PKCE. So I think it’s safer to leave the recommendation
as-is.

On 23 Jul 2019, at 08:28, Dominick Baier  wrote:

Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site Request Forgery and
   authorization code swap attacks and MUST use a unique value for each
   authorization request, and MUST verify the returned state in the
   authorization response matches the original state the app created.

Isn’t state optional when PKCE is used?

thanks
———
Dominick

On 22. July 2019 at 08:14:33, Dominick Baier (dba...@leastprivilege.com)
wrote:

Hey,

Just read the spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisation of the “Application
Architecture Patterns”. I definitely want to distinguish between
applications only accessing same-site back-end services and “others”. Not
sure if “dynamic application server" and “static application server” should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don’t have
the right answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource Server

> OAuth and OpenID Connect provide very little benefit in this
   deployment scenario, so it is recommended to reconsider whether you
   need OAuth or OpenID Connect at all in this case.

I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.


6.2.  Apps Served from a Dynamic Application Server

I have a .NET sample for that

https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#section-9.7>.
Content-Security Policy

A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#ref-CSP2>])
or similar mechanism.



I would rather say that ANY JS app should use CSP to lock down the browser
features to a minimal attack surface. In addition, if refresh or access
tokens are involved - further settings like disabling inline scripting
(unsafe inline) and eval should be disabled.

Thanks for doing this work!

———
Dominick

___
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] Feedback on OAuth for browser-based Apps

[Dominick Baier]

Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site Request Forgery and
   authorization code swap attacks and MUST use a unique value for each
   authorization request, and MUST verify the returned state in the
   authorization response matches the original state the app created.

Isn’t state optional when PKCE is used?

thanks
———
Dominick

On 22. July 2019 at 08:14:33, Dominick Baier (dba...@leastprivilege.com)
wrote:

Hey,

Just read the spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisation of the “Application
Architecture Patterns”. I definitely want to distinguish between
applications only accessing same-site back-end services and “others”. Not
sure if “dynamic application server" and “static application server” should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don’t have
the right answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource Server

> OAuth and OpenID Connect provide very little benefit in this
   deployment scenario, so it is recommended to reconsider whether you
   need OAuth or OpenID Connect at all in this case.

I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.


6.2.  Apps Served from a Dynamic Application Server

I have a .NET sample for that

https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#section-9.7>.
Content-Security Policy


   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#ref-CSP2>])
or similar mechanism.



I would rather say that ANY JS app should use CSP to lock down the browser
features to a minimal attack surface. In addition, if refresh or access
tokens are involved - further settings like disabling inline scripting
(unsafe inline) and eval should be disabled.

Thanks for doing this work!

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

[OAUTH-WG] Feedback on OAuth for browser-based Apps

[Dominick Baier]

Hey,

Just read the spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisation of the “Application
Architecture Patterns”. I definitely want to distinguish between
applications only accessing same-site back-end services and “others”. Not
sure if “dynamic application server" and “static application server” should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don’t have
the right answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource Server

> OAuth and OpenID Connect provide very little benefit in this
   deployment scenario, so it is recommended to reconsider whether you
   need OAuth or OpenID Connect at all in this case.

I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.


6.2.  Apps Served from a Dynamic Application Server

I have a .NET sample for that

https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7 
.
Content-Security Policy

   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2
])
or similar mechanism.



I would rather say that ANY JS app should use CSP to lock down the browser
features to a minimal attack surface. In addition, if refresh or access
tokens are involved - further settings like disabling inline scripting
(unsafe inline) and eval should be disabled.

Thanks for doing this work!

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

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Dominick Baier]

+1

———
Dominick

On 8. April 2019 at 20:21:21, William Denniss (
wdenniss=40google@dmarc.ietf.org) wrote:

I support adoption of this draft as a working group document.

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher  wrote:

> +1 for me as well :)
>
> On 4/8/19 1:38 PM, Hans Zandbelt wrote:
>
> +1
>
> Hans.
>
> On Mon, Apr 8, 2019, 19:34 John Bradley  wrote:
>
>> I agree this should be adopted as a working group document.
>>
>>
>> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
>> > Hi all,
>> >
>> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
>> Tokens'?? document following the positive feedback at the last IETF meeting
>> in Prague.
>> >
>> > Here is the document:
>> > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>> >
>> > Please let us know by April 22nd whether you accept / object to the
>> > adoption of this document as a starting point for work in the OAuth
>> > working group.
>> >
>> > 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 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Dominick Baier]

t;>
>> Thanks for writing this up. One comment on auth_time...
>>
>> auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core 
>> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>>   Important: as this claim represents the time at which the end user
>>   authenticated, its value will remain the same for all the JWT
>>   access tokens issued within that session.  For example: all the
>>   JWT access tokens obtained with a given refresh token will all
>>   have the same value of auth_time, corresponding to the instant in
>>   which the user first authenticated to obtain the refresh token.
>>
>>
>> During a current session a user can be challenged for additional
>> credentials or required to re-authenticate due to a number of different
>> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
>> I'd assume that the auth_time value should be updated to the latest time at
>> which the user authenticated.
>>
>> If we need a timestamp for when the "session" started, then there could
>> be a session_start_time claim.
>>
>> Thanks,
>> George
>>
>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>- Despite OAuth2 not requiring any specific format for ATs, through
>>the years I have come across multiple proprietary solution using JWT for
>>their access token. The intent and scenarios addressed by those solutions
>>are mostly the same across vendors, but the syntax and interpretations in
>>the implementations are different enough to prevent developers from 
>> reusing
>>code and skills when moving from product to product.
>>- I asked several individuals from key products and services to share
>>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and 
>> explanations!
>>).
>>I studied and compared all those instances, identifying commonalities
>>and differences.
>>- I put together a presentation summarizing my findings and
>>suggesting a rough interoperable profile (slides:
>>
>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>
>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>) - got early feedback from Filip Skokan on it. Thx Filip!
>>- The presentation was followed up by 1.5 hours of unconference
>>discussion, which was incredibly valuable to get tight-loop feedback and
>>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>>and contributed generously to the discussion. Thank you!!!
>>Note: if you were at OSW2019, participated in the discussion and
>>didn't get credited in the draft, my apologies: please send me a note and
>>I'll make things right at the next update.
>>- On my flight back I did my best to incorporate all the ideas and
>>feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>>Hannes and above all Brian were all super helpful in negotiating the
>>mysterious syntax of the RFC format and submission process.
>>
>> I was blown away by the availability, involvement and willingness to
>> invest time to get things right that everyone demonstrated in the process.
>> This is an amazing community.
>> V.
>>
>> ___
>> 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/oaut

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Dominick Baier]

>From an access token consumer (aka API) developer point of view, I prefer
this logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote:

Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or
incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances,
it’ll works fine. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci  wrote:

Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID
Connect core, hence Dominick observation is on point. However in the
description I express something in line with 7519, which was in fact my
intent.

The idea was to provide an identifier of the calling subject that is
guaranteed to be present in all cases- this would allow an SDK developer to
use the same code for things like lookups and membership checks regardless
of the nature of the caller (user in a delegated case, app in app-only
grants). The information to discriminate between user and app callers is
always available in the token (say, the caller is a user if sub!=client_id,
where client_id is always guaranteed to be present as well) hence there's
no loss in expressive power, should that difference be relevant for the
resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking
of in this case. Of course, if this would introduce a risk I completely
agree it should be changed- I'd just like to understand better the problem.
Could you expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have
the same identifier within an IDP? When using collision resistant IDs, as
it is usually the case, that seems to be a remote possibility- did you
stumble in such scenario in production?

Thanks
V.


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt 
wrote:

> I believe there are plenty of OAuth 2.0 only use cases out there... but
> nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
>
> Hans.
>
> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier 
> wrote:
>
>> Yes I know - and I think in hindsight it was a mistake to use the same
>> claim type for multiple semantics.
>>
>> All the “this is OIDC not OAuth” arguments are making things more
>> complicated than they need to be - in my experience almost no-one (that I
>> know) does OIDC only - nor OAuth only. They always combine it.
>>
>> In reality this leads to potential security problems - this spec has the
>> potential to rectify the situation.
>>
>> Dominick
>>
>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandb...@zmartzone.eu)
>> wrote:
>>
>> Without agreeing or disagreeing: OIDC does not apply here since it is not
>> OAuth and an access token is not an id_token.
>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>>
>> "The "sub" (subject) claim identifies the principal that is the
>>subject of the JWT.  The claims in a JWT are normally statements
>>about the subject.  The subject value MUST either be scoped to be
>>locally unique in the context of the issuer or be globally unique.
>>The processing of this claim is generally application specific"
>>
>> which kind of spells "client" in case of the client credentials grant but
>> I also do worry about Resource Servers thinking/acting only in terms of
>> users
>>
>> Hans.
>>
>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier 
>> wrote:
>>
>>> IMHO the sub claim should always refer to the user - and nothing else.
>>>
>>> OIDC says:
>>>
>>> "Subject - Identifier for the End-User at the Issuer."
>>>
>>> client_id should be used to identify clients.
>>>
>>> cheers
>>> Dominick
>>>
>>> On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote:
>>>
>>> Hi Vittorio,
>>>
>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>
>>> One feedback.
>>> The “sub” claim can include 2 types of identifier, end-user and client,
>>> in this spec.
>>> It requires those 2 types

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Dominick Baier]

Yes I know - and I think in hindsight it was a mistake to use the same
claim type for multiple semantics.

All the “this is OIDC not OAuth” arguments are making things more
complicated than they need to be - in my experience almost no-one (that I
know) does OIDC only - nor OAuth only. They always combine it.

In reality this leads to potential security problems - this spec has the
potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandb...@zmartzone.eu)
wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not
OAuth and an access token is not an id_token.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

"The "sub" (subject) claim identifies the principal that is the
   subject of the JWT.  The claims in a JWT are normally statements
   about the subject.  The subject value MUST either be scoped to be
   locally unique in the context of the issuer or be globally unique.
   The processing of this claim is generally application specific"

which kind of spells "client" in case of the client credentials grant but I
also do worry about Resource Servers thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier 
wrote:

> IMHO the sub claim should always refer to the user - and nothing else.
>
> OIDC says:
>
> "Subject - Identifier for the End-User at the Issuer."
>
> client_id should be used to identify clients.
>
> cheers
> Dominick
>
> On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote:
>
> Hi Vittorio,
>
> Thanks for the good starting point of standardizing JWT-ized AT.
>
> One feedback.
> The “sub” claim can include 2 types of identifier, end-user and client, in
> this spec.
> It requires those 2 types of identifiers to be unique each other in the
> IdP context.
>
> I prefer omitting “sub” claim in 2-legged context, so that no such
> constraint needed.
>
> thanks
>
> nov
>
> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
> vittorio.bertocci=40auth0@dmarc.ietf.org> wrote:
>
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
> Here's just a bit of backstory, in case you are interested in how this doc
> came to be. The trajectory it followed is somewhat unusual.
>
>- Despite OAuth2 not requiring any specific format for ATs, through
>the years I have come across multiple proprietary solution using JWT for
>their access token. The intent and scenarios addressed by those solutions
>are mostly the same across vendors, but the syntax and interpretations in
>the implementations are different enough to prevent developers from reusing
>code and skills when moving from product to product.
>- I asked several individuals from key products and services to share
>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>I studied and compared all those instances, identifying commonalities
>and differences.
>- I put together a presentation summarizing my findings and suggesting
>a rough interoperable profile (slides:
>
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>
> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>) - got early feedback from Filip Skokan on it. Thx Filip!
>- The presentation was followed up by 1.5 hours of unconference
>discussion, which was incredibly valuable to get tight-loop feedback and
>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>and contributed generously to the discussion. Thank you!!!
>Note: if you were at OSW2019, participated in the discussion and
>didn't get credited in the draft, my apologies: please send me a note and
>I'll make things right at the next update.
>- On my flight back I did my best to incorporate all the ideas and
>feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>Hannes and above all Brian were all super helpful in negotiating the
>mysterious syntax of the RFC format and submission process.
>
> I was blown away by the availability, involvement and willingness to
> invest time to get

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Dominick Baier]

IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in
this spec.
It requires those 2 types of identifiers to be unique each other in the IdP
context.

I prefer omitting “sub” claim in 2-legged context, so that no such
constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <
vittorio.bertocci=40auth0@dmarc.ietf.org> wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access
tokens. You can find it in
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc
came to be. The trajectory it followed is somewhat unusual.

   - Despite OAuth2 not requiring any specific format for ATs, through the
   years I have come across multiple proprietary solution using JWT for their
   access token. The intent and scenarios addressed by those solutions are
   mostly the same across vendors, but the syntax and interpretations in the
   implementations are different enough to prevent developers from reusing
   code and skills when moving from product to product.
   - I asked several individuals from key products and services to share
   with me concrete examples of their JWT access tokens (THANK YOU Dominick
   Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
   (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
   I studied and compared all those instances, identifying commonalities
   and differences.
   - I put together a presentation summarizing my findings and suggesting a
   rough interoperable profile (slides:
   
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
   
<https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
   ) - got early feedback from Filip Skokan on it. Thx Filip!
   - The presentation was followed up by 1.5 hours of unconference
   discussion, which was incredibly valuable to get tight-loop feedback and
   incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
   Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
   contributed generously to the discussion. Thank you!!!
   Note: if you were at OSW2019, participated in the discussion and didn't
   get credited in the draft, my apologies: please send me a note and I'll
   make things right at the next update.
   - On my flight back I did my best to incorporate all the ideas and
   feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
   Hannes and above all Brian were all super helpful in negotiating the
   mysterious syntax of the RFC format and submission process.

I was blown away by the availability, involvement and willingness to invest
time to get things right that everyone demonstrated in the process. This is
an amazing community.
V.
___
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] popular apps that use appauth?

[Dominick Baier]

A good example of a desktop application using browser authentication is
Github for Desktop.

They use custom URLs/callbacks for both OSX and Windows. Works very well.

———
Dominick

On 25. February 2019 at 11:48:20, Vittorio Bertocci (
vittorio=40auth0@dmarc.ietf.org) wrote:

Ahh, as John knows this is a big pet peeve for me :)

Although that's all true on mobile, on desktop things are more
complicated.

   - Using a system browser on the desktop (Linux/Mac/Windows) means that
   you don't control the experience (there might be modal dialogs occluding
   the browser or any other Z order windows factors; the browser instance
   might have already other tabs open; the default browser of any particular
   machine can be different; users might need to take steps to get back to the
   app; etc)
   - Use of loopback adapters is banned by many big enterprises on their
   machines
   - The big security advantages of the approach on mobile, where apps are
   all nicely sandboxed, is not as pronounced in an environment where the user
   login session in the machine is the main security boundary (think keylogger
   attaching to the main windows events pump, or a debugger - all stuff not
   possible on mobile but viable on desktops)

True, it would be fantastic if desktop OSes would offer system browser
features comparable to what's available on iOS and Android - but today that
doesn't appear to be the case. And the inability to leverage existing
sessions when using embedded views on the desktop is a true pain. But
judging from the behavior of the most popular desktop apps in market
(Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for
Mac...) losing the ability to access cookies is less of a nuisance for
users than all of the above. And considering that desktop machines usually
have their own way of identifying devices, that is also not much of a
factor for desktop apps.

The best practice has been discussed for the last 4 years and still all of
the big apps above remain on embedded: it is however telling that the
mobile apps from the same vendors all embraced the system browser approach.
Since the native best practices came out, I have been working with desktop
developers dealing with this cognitive dissonance of the best practice
saying something that is very hard to put in practice. I understand that it
is well intentioned and it is easier to give one single advice for both
mobile and desktop, but while the necessary features and experiences are
lacking on the desktop I am not sure how much of a difference it is making
in that use case.



On Mon, Feb 25, 2019 at 12:59 AM David Waite 
wrote:

>
> > On Feb 24, 2019, at 10:43 AM, William Denniss  40google@dmarc.ietf.org> wrote:
> >
> > For 1P sign-in, there are several good reasons to go with
> ASWebAuthenticationSession, like syncing the signed-in session with Safari
> and using it if it already exists.
>
> With enterprise 3P, you’ll have to use some web agent for authentication
> pretty much no matter what, and you’ll almost certainly get pressure to use
> ASWebAuthenticationSession, and/or potentially lose deals to competitors
> during product evaluations. It is simply what is required for robust
> integration into a corporate infrastructure.
>
> For 1P on iOS, it depends on the complexity of authentication for first
> party. If you are just doing password and maybe SMS-based challenges, there
> is decent enough native app integration for password sharing and SMS
> keyboard for that to keep conversions high, even with having to
> authenticate twice.
>
> However, if you want to authenticate the device (even pseudonymously with
> session cookies) or do other factors, the authentication is simpler with
> ASWebAuthenticationSession. Which means your life will be easier if you
> have more complex authentication requirements anywhere on your roadmap to
> just start off using ASWebAuthenticationSession.
>
> It is likely that future authentication technologies like WebAuthn will
> not work with an embedded web view. The ability to arbitrarily inject
> javascript means that apps can phish webauthn responses for domains via
> embedded web views.
>
> -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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] popular apps that use appauth?

[Dominick Baier]

The Uber app uses it for their OAuth flow to PayPal e.g.

———
Dominick

On 23. February 2019 at 18:05:33, Brock Allen (brockal...@gmail.com) wrote:

I often have push back from customers (mainly the marketing department/UX
folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They
ask for examples of any other popular or well known apps that follow this
practice. Does anyone on this list have examples?

TIA

-Brock

___
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] MTLS endpoints & discovery (was something else)

[Dominick Baier]

+1

———
Dominick

On 21. February 2019 at 09:35:35, Dave Tonge (dave.to...@momentumft.co.uk)
wrote:

+1 for mtls_endpoints optional metadata

Dave Tonge



On Thu, 21 Feb 2019 at 00:09, John Bradley  wrote:

> I agree.
>
> If someone really wants separate meta-data nothing stops them from having
> a separate AS with its own meta-data.
>
> John B.
> On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
>
> +1 for defining an optional mtls endpoints section
>
> I first leaned towards a second metadata file, mainly due to the potential
> token endpoint authentication method issue. But adding a secondary metadata
> configuration just for this purpose seems a bit over engineered and would
> take a lot of normative language to get it right. Just as an example: does
> the second configuration overload or replace the primary one? On the other
> hand, any client using looking for mtls based token endpoint authentication
> methods must be aware of the potential mtls endpoints section. So I think
> their is no real issue.
>
> Am 20.02.2019 um 17:59 schrieb Filip Skokan  >:
>
> +1, great summary
>
> Odesláno z iPhonu
>
> 20. 2. 2019 v 16:10, Brian Campbell <
> bcampbell=40pingidentity@dmarc.ietf..org
> >:
>
> The objective is to allow the AS to provide MTLS negotiating endpoints on
> a different host and/or port so that any non-desirable side effects of
> requesting client certificates during the TLS handshake can be avoided for
> 'regular' clients that are not doing any MTLS.
>
> In all likelihood, I'd expect that any pair of MTLS and regular endpoints
> have the same application logic behind them. And that just the TLS setup
> that differs to accommodate the aforementioned objective. That means that
> they'd support the same client authentication methods but the MTLS endpoint
> would just be set up so as to get MTLS to work. When first considering it,
> that seemed a bit overreaching for the spec to come out and say and more of
> a deployment thing for the AS. But maybe being more prescriptive would
> reduce some of the professed problematic ambiguity. As mentioned in a
> previous message, referring to the mtls endpoints as aliases might be
> useful in indicating that they are the same endpoint that is just known and
> accessed differently based on the context of use.
>
> I'll grant that some of the wording in RFC 8414 can be awkward with
> respect to this kind of extension. Calling it a violation is a bit over the
> top though. And as much as we might try to write specs that are the final
> word, there's the realities of how usage and understanding unfold in
> practice. As one example, there's some discussion of the treatment of some
> of the metadata in this  section of a blog post about a different spec
> being developed
> https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00..
> Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being
> pragmatic in the given circumstances. I suppose opinions will differ.
>
> It turns out that writing these specifications is kinda hard. Even when
> people share the same objective (and that's often not even the case),
> opinions can differ about what actually constitutes simplicity. It seems
> that's where we are now.
>
> My stance as an individual is that the mtls_endpoints (or
> mtls_endpoint_aliases) approach is reasonable and pragmatic and the most
> straightforward and simple of the options put forth (i.e.. vs a metadata
> parameter linking to or well-known locations to completely separate
> metadata documents). As an editor, I acknowledge that there's been
> disagreement about it while also noting again that the dissenting voices
> come from a vocal minority of a few individuals.
>
>
>
>
> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
>> Neil’s example demonstrates how the mtls_endpoints approach leads to
>> confusion. Consider the following metadata fragment:
>>
>>
>>
>> {
>>
>>   “token_endpoint”: “https://as.example..com/token
>> ”,
>>
>> “token_endpoint_auth_methods_supported”: [ “client_secret_basic”,
>> “tls_client_auth” ],
>>
>> “mtls_endpoints”: {
>>
>>   “token_endpoint”: “https://as.example.com/mtls/token”
>>
>> }
>>
>> }
>>
>>
>>
>> Which of these statements about endpoints on https://as.example.com/ are
>> true?
>>
>>1. The /token endpoint only supports client_secret_basic, and
>>/mtls/token only supports tls_client_auth.
>>2. The /token endpoint supports both methods, and /mtls/token only
>>supports tls_client_auth.
>>3. Both /token and /mtls/token support both methods.
>>
>>
>>
>> All of these could be reasonable interpretations of this metadata. When
>> properties mean different things in different contexts, ambiguity abounds.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

[Dominick Baier]

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in
mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR
that, or send values in arbitrary order adds to complexity. Complexity is
the natural enemy of security.

Cheers
———
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (
richa...@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the
semantics of a parameter it defines. We should be very, very, VERY careful
about telling implementers to violate an existing standard. This change
might prove incompatible with existing or future implementations of 8414,
it might not, but by violating the standard the proposal creates an
opportunity for incompatibility that didn’t exist before.



As far as simplicity is concerned, I find a solution that reuses the
existing data model and naturally supports existing and future extensions
to be far simpler than one that introduces ambiguous semantics to existing
parameters. Generally speaking, data models with properties that mean
different things in different contexts tend to be fragile and require more
complex code to work with. But that’s just my experience as, you know, an
actual developer.



Let’s keep the assumptions and snide remarks about others’ backgrounds off
the list, please.



-- 

Annabelle Richard Backman

AWS Identity





*From: *Dominick Baier 
*Date: *Wednesday, February 13, 2019 at 4:18 AM
*To: *"Richard Backman, Annabelle" , Filip Skokan <
panva...@gmail.com>
*Cc: *Brian Campbell , "Richard Backman,
Annabelle" , oauth 
*Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery



I am for keeping it simple and not introducing another link to follow.



I sometimes wonder how many of the spec authors are actually developers -
these suggestions make software unnecessary complex ;)



———

Dominick



On 13. February 2019 at 12:25:13, Filip Skokan (panva...@gmail.com) wrote:

Hello,



Additionally, a metadata document that omits token_endpoint in favor of
mtls_endpoints since only mTLS is supported would violate 8414, as 8414
says token_endpoint “is REQUIRED unless only the implicit grant type is
supported.”


mtls only AS doesn't get anything out of using mtls_endpoints, its use
should not be recommended for such AS and regular endpoints will be used,
this satisfies the requirement

Here is one example, based on my understanding of the “straw man” format
presented in this thread: RFC8414 defines the value of
token_endpoint_auth_methods_supported as a “JSON array containing a list of
client authentication methods supported by this token endpoint.” If that
array contains “tls_client_auth” and the endpoint specified in
token_endpoint does not support mTLS, then that metadata violates 8414. You
could address this by adding a token_endpoint_auth_methods_supported
parameter to the mtls_endpoints object, and likewise for the other
endpoints and auth methods. If you take that to its logical conclusion, you
end up with a complete metadata document hanging off of mtls_endpoints.
It’s that line of thought that led me to suggest just pointing to an
alternate document.


Assuming we go with using the same root auth methods property, what's the
issue? Clients not having mtls capabilities won't care about the additional
method members being present. Clients that do implement mtls by the
specification will know to look for mtls_endpoints and fall back to regular
ones if the specific endpoint or mtls_endpoints root property is not
present.



I gave `mtls_alternate_metadata` route a thought and don't see how it
helps, given the two above are non-issues (my $.02) another discovery
document only brings more of them since every property can now be
different, not just the endpoints.


S pozdravem,
*Filip Skokan*





On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <
richa...@amazon.com> wrote:

Here is one example, based on my understanding of the “straw man” format
presented in this thread: RFC8414 defines the value of
token_endpoint_auth_methods_supported as a “JSON array containing a list of
client authentication methods supported by this token endpoint.” If that
array contains “tls_client_auth” and the endpoint specified in
token_endpoint does not support mTLS, then that metadata violates 8414. You
could address this by adding a token_endpoint_auth_methods_supported
parameter to the mtls_endpoints object, and likewise for the other
endpoints and auth methods. If you take that to its logical conclusion, you
end up with a complete metadata document hanging off of mtls_endpoints.
It’s that line of thought that led me to suggest just pointing to an
alternate document.



Additionally, a metadata document that omits token_endpoint in favor of
mtls_endpoints since only mTLS is supported would violate 8414, as 8414
says token_endpoint “is REQUIRED unl

Re: [OAUTH-WG] MTLS token endoint & discovery

[Dominick Baier]

ints would not be
> recommended for mtls-only AS but recommended for one with both mtls/regular
> authentication methods. token_endpoint remains required for all intents and
> purposes. And as for the usable client authentication methods - they should
> all be listed, or do you think we should separate the ones for each
> hostname/port location? To what end? Is there a risk having the mtls
> hostname/port accepting regular requests? Other then secret/key _jwt auth
> methods assertion aud claim the endpoint location doesn't play a role in
> the authentication process.
>
>
> Best,
> *Filip*
>
>
>
>
>
> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
> I’m not opposed to introducing a metadata change, if the scenario is
> relevant and other approaches can’t adequately address it – and I’ll
> readily grant that we probably don’t want to depend on consistency of
> browser behavior at the intersection of client certificates and
> Access-Control-Allow-Credentials. But care needs to be taken in designing
> that metadata to avoid violating or otherwise negatively impacting usage of
> RFC8414.
>
>
>
> Along those lines, instead of adding an “mtls_endpoints” metadata
> parameter, we could add an “mtls_alternate_metadata” parameter whose value
> is the URL of an alternate metadata document intended for clients using
> mTLS. An mTLS-optional AS could have two different metadata documents for
> mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the
> mTLS-only scenario. This sidesteps the challenges of aligning the
> “either/or” semantics of mTLS-optional with some of the rigid parameter
> definitions in RFC8414 (see: token_endpoint,
> token_endpoint_auth_methods_supported).
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From:* OAuth  on behalf of Brian Campbell
> 
> *Date:* Tuesday, February 12, 2019 at 10:58 AM
> *To:* Dominick Baier 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>
>
>
> Thanks for the input, Dominick.
>
>
>
> I'd said previously that I was having trouble adequately gauging whether
> or not there's sufficient consensus to go ahead with the update. I was even
> thinking of asking the chairs about a consensus call during the office
> hours meeting yesterday. But it got canceled. And looking again back over
> the discussion, I don't believe a consensus call is necessary. There's been
> a lot of general discussion over the last several weeks during which
> several folks have stated support for the proposal while there's been only
> one voice of direct dissent. That seems like rough enough consensus and, as
> such, I plan to make the change in the next revision of the document (which
> should be done soon). Chairs, please let me know, if you believe the
> situation warrants a different course of action.
>
>
>
>
>
>
>
> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier 
> wrote:
>
> IMHO that’s a reasonable and pragmatic option.
>
>
>
> Thanks
>
> ———
>
> Dominick
>
>
>
> On 11. February 2019 at 13:26:37, Brian Campbell (
> bcampb...@pingidentity.com) wrote:
>
> It's been pointed out that the potential issue is not isolated to the just
> token endpoint but that revocation, introspection, etc. could be impacted
> as well. So,  at this point, the proposal on the table is to add a new
> optional AS metadata parameter named 'mtls_endpoints' that's value we be a
> JSON object which itself contains endpoints that, when present, a client
> doing MTLS would use rather than the regular endpoints.  A straw-man
> example might look like this
>
> {
>   "issuer":"https://server.example.com";,
>   "authorization_endpoint":"https://server.example.com/authz";,
>   "token_endpoint":"https://server.example.com/token";,
>   "token_endpoint_auth_methods_supported":[
>  "client_secret_basic","tls_client_auth", "none"],
>   "userinfo_endpoint":"https://server.example.com/userinfo";,
>   "revocation_endpoint":"https://server.example.com/revo";,
>   "jwks_uri":"https://server.example.com/jwks.json";,
>
>
>
>
> *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token
> <https://mtls.example.com/token>",
> "userinfo_endpoint":"https://mtls.example.com/userinfo
> <https://mtls.example.com/userinfo>",
> "revocation_endpoint":"https://mtls.example.com/

Re: [OAUTH-WG] MTLS token endoint & discovery

[Dominick Baier]

IMHO that’s a reasonable and pragmatic option.

Thanks
———
Dominick

On 11. February 2019 at 13:26:37, Brian Campbell (bcampb...@pingidentity.com)
wrote:

It's been pointed out that the potential issue is not isolated to the just
token endpoint but that revocation, introspection, etc. could be impacted
as well. So,  at this point, the proposal on the table is to add a new
optional AS metadata parameter named 'mtls_endpoints' that's value we be a
JSON object which itself contains endpoints that, when present, a client
doing MTLS would use rather than the regular endpoints.  A straw-man
example might look like this

{
  "issuer":"https://server.example.com";,
  "authorization_endpoint":"https://server.example.com/authz";,
  "token_endpoint":"https://server.example.com/token";,
  "token_endpoint_auth_methods_supported":[
 "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo";,
  "revocation_endpoint":"https://server.example.com/revo";,
  "jwks_uri":"https://server.example.com/jwks.json";,




*"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token
<https://mtls.example.com/token>",
"userinfo_endpoint":"https://mtls.example.com/userinfo
<https://mtls.example.com/userinfo>",
"revocation_endpoint":"https://mtls.example.com/revo
<https://mtls.example.com/revo>"   }*
}


A client doing MTLS would look for and give precedence to an endpoint under
"mtls_endpoints" while falling back to use the normal endpoint from the top
level of metadata when/if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) will use the
regular endpoints. And only the host/port of the endpoints listed in
mtls_endpoints will be set up to request TLS client certificates during
handshake. Thus any potential impact of the CertificateRequest message
being sent in the TLS handshake can be avoided for all the other regular
clients that are not going to do MTLS - including and most importantly
in-browser javascript clients where there can be less than desirable UI
presented to the end-user.

I'm struggling, however, to adequately gauge whether or not there's
sufficient consensus to go ahead with the update. There's been some support
for it voiced. As well as talk of other approaches that could be
alternatives or additional measures. And also some vocal opposition to it.


On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier 
wrote:

> We are currently implementing MTLS in IdentityServer.
>
> Our approach will be that we’ll offer a separate token endpoint that
> supports client certs. Are you planning on adding an official endpoint name
> for discovery? Right now we are using “mtls_token_endpoint”.
>
> Thanks
> ———
> Dominick
>
> On 7. February 2019 at 22:36:55, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good
> reminder that even a seemingly innocuous change that should be backwards
> compatible can break things unexpectedly..
>
>
>
>
>
> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
>
>> The case I’m referencing didn’t specifically involve AS metadata. We had
>> clients in the wild that assumed that all the properties in the JSON object
>> returned from our userinfo endpoint were scalar strings. This broke when we
>> introduced a new property whose value was a JSON object. It was a good
>> reminder that even a seemingly innocuous change that should be backwards
>> compatible can force more work on clients than we expect.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> *From:* Brian Campbell 
>> *Date:* Wednesday, February 6, 2019 at 11:30 AM
>> *To:* "Richard Backman, Annabelle" 
>> *Cc:* "Richard Backman, Annabelle" , oauth <
>> oauth@ietf.org>
>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>> clients using the token endpoint
>>
>>
>>
>> And I'm honestly really struggling to see what could have gone wrong with
>> or how token_endpoint_auth_methods broke something with the user info
>> endpoint. If you have the time and/or it'd be informative to this here
>> little discussion, please explain that one a bit more.
>>
>>
>>
>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <
>> bcampb...@pingidenti

[OAUTH-WG] MTLS token endoint & discovery

[Dominick Baier]

We are currently implementing MTLS in IdentityServer.

Our approach will be that we’ll offer a separate token endpoint that
supports client certs. Are you planning on adding an official endpoint name
for discovery? Right now we are using “mtls_token_endpoint”..

Thanks
———
Dominick

On 7. February 2019 at 22:36:55, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good
reminder that even a seemingly innocuous change that should be backwards
compatible can break things unexpectedly..





On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> The case I’m referencing didn’t specifically involve AS metadata. We had
> clients in the wild that assumed that all the properties in the JSON object
> returned from our userinfo endpoint were scalar strings. This broke when we
> introduced a new property whose value was a JSON object. It was a good
> reminder that even a seemingly innocuous change that should be backwards
> compatible can force more work on clients than we expect.
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From:* Brian Campbell 
> *Date:* Wednesday, February 6, 2019 at 11:30 AM
> *To:* "Richard Backman, Annabelle" 
> *Cc:* "Richard Backman, Annabelle" , oauth <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
> clients using the token endpoint
>
>
>
> And I'm honestly really struggling to see what could have gone wrong with
> or how token_endpoint_auth_methods broke something with the user info
> endpoint. If you have the time and/or it'd be informative to this here
> little discussion, please explain that one a bit more.
>
>
>
> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell 
> wrote:
>
> "far" should have said "fair" in the previous message
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell 
> wrote:
>
> It may well be due to my own intellectual shortcomings but these
> issues/questions/confusion-points are not resonating for me as being
> problematic.
>
>
>
> The more general stance of "this isn't needed or worth it in this
> document" (I think that's far?) is being heard though.
>
>
>
>
>
>
>
> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
> (TL;DR: punt AS metadata to a separate draft)
>
> AS points #1-3 are all questions I would have as an implementer:
>
>1. Section 2 of RFC8414 
>says token_endpoint “is REQUIRED unless only the implicit grant type is
>supported.” So what does the mTLS-only AS put here?
>2. The claims for these other endpoints are OPTIONAL, potentially
>leading to inconsistency depending on how #1 gets decided.
>3. The example usage of the token_endpoint_auth_methods property given
>earlier is incompatible with RFC8414, since some of its contents are only
>valid for the non-mTLS endpoints, and others are only valid for the mTLS
>endpoints. Hence this question.
>4. This introduces a new metadata property that could impact how other
>specs should extend AS metadata. That needs to be addressed.
>
>
>
> I could go on for client points but you already get the point. Though I’ll
> share that #3 is real and once forced me to roll back an update to the
> Login with Amazon userinfo endpoint…good times. 😃
>
>
>
> I don’t necessarily think an AS metadata property is wrong per se, but
> understand that you’re bolting a layer of flexibility onto a standard that
> wasn’t designed for that, and I don’t think the metadata proposal as it’s
> been discussed here sufficiently deals with the fallout from that. In my
> view this is a complex enough issue and it’s for a nuanced enough use case
> (as far as I can tell from discussion? Please correct me if I’m wrong) that
> we should punt it to a separate draft (e.g., “Authorization Server Metadata
> Extensions for mTLS Hybrids”) and get mTLS out the door.
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From:* OAuth  on behalf of Brian Campbell
> 
> *Date:* Monday, February 4, 2019 at 5:28 AM
> *To:* "Richard Backman, Annabelle" 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
> clients using the token endpoint
>
>
>
> Those points of confusion strike me as somewhat hypothetical or
> hyperbolic. But your general point is taken and your position of being anti
> additional metadata on this issue is noted.
>
>
>
> All of which leaves me a bit uncertain about how to proceed. There seem to
> be a range of opinions on this point and gauging consensus is proving
> elusive for me. That's confounded by my own opinion on it being somewhat
> fluid.
>
>
>
> And I'd really like to post an update to this draft about a month or two
> ago.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote

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

[Dominick Baier]

I agree with Vittorio -

While we all agree that implicit is outdated and we can do better (and it
is indeed good that this discussion has finally started for real) - the
communication around the (preliminary) results of the BCP was unfortunate
and not very responsible - quoting:

“Simply put, the implicit grant’s security is broken beyond repair. It is
vulnerable to access token leakage, meaning an attacker can exfiltrate
valid access tokens and use it to his own benefit. This might for example
result in the attacker accessing the legit user’s health record or
initiating a payment, from her bank account."

This indeed, as Vittorio pointed out, sounds like a new vulnerability has
been found. This spreads FUD ;)

Also - simply saying “implicit is evil - switch to code” means for most
people also using refresh token - so we are treating access tokens in the
URL with refresh tokens in session storage (over simplified - but you get
the idea).

Again we all agree that implicit can be improved - but there are some
issues to be sorted first to make this a smooth transition.

My 2c

———
Dominick

On 3. December 2018 at 11:59:44, Vittorio Bertocci (
vittorio.bertocci=40auth0@dmarc.ietf.org) wrote:

Hi all,
Sorry for stepping a bit back from the level of detail the discussion
already reached. I do have some specific comments on the document, but
before bringing those up I wanted to raise a general problem I am
experiencing with this initiative..

I have a number of customers that are reacting to the news with distress.
The language used in some of the communications associated with this
initiative made them feel like some new vulnerability was discovered,
calling for immediate action.
The fact is that as far as I can tell, no new, previously unknown fact
informed this decision: no new vulnerability, nor any new technology that
wasn’t available before (the sender constrain is still not actionable for
most customers). The risks of the implicit flow aren’t bigger now than they
were in October.
That doesn’t mean that we cannot improve guidance, of course- and now is as
good as any other moment to do so: but at the same time, I think we need to
be cognizant of the *immense* investment in existence today in form of SDKs
and applications built on those SDKs that are predicated on implicit flow,
with our blessing: until very recently the official position was “implicit
is bad but it’s the best we have noawadays”.
To me, being cognizant of that means that we should help people to
formulate action proportionate to the risk. And if until yesterday we were
ok with them using implicit, we cannot realistically expect anyone to start
changing all of their apps today, but that’s the message many customers are
getting.
TL;DR, I think the community would be well served by clarifying in the
security document that there is no new risk and their existing codebase
didn’t suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache with
milder side effects than the one we were prescribing them until now, but
that doesn’t mean that they should throw away all the stash they have of
the older drug. The old drug will keep working as it worked until now. Once
they run out of their stash, they should get the new one; or if the old
side effects were particularly bad for them, perhaps they should consider
switching today. But this isn’t a recall.

And if in fact this group thinks it should be a recall and get everyone off
the old one right now, I think we’ll need to make a much stronger case than
we have done so far.

Thoughts?

Thanks
V.


On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt 
wrote:

> Hi Hannes,
>
> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
> >
> > I agree with Aaron here and I think Section 3.8.1.2 of
> draft-ietf-oauth-security-topics-10  already does a pretty good job.
>
> my proposal is to add the following definition (based on 3.8.1.2) to a new
> „Terminology" section or to section 2.1.2:
>
> A sender constrained access token scopes the applicability of an access
> token to a certain sender.  This sender is
> obliged to demonstrate knowledge of a certain secret as prerequisite for
> the acceptance of that token at the recipient (e.g. a resource server).
>
> >
> > I was, however, wondering about the subtle implication of the
> requirement for sender constrained tokens. My understanding of the token
> binding discussion, which is one of the ways to provide sender-constrained
> tokens, is that we don’t have good faith in seeing deployment anytime soon.
> Hence, we are essentially (reading in between the lines of Section 3.8.1.2)
> saying that you cannot use implicit grant in a practical setup for the
> web*..
>
> The text shall convey that implicit must not be used at all. The main
> reason being it is unprotected against token injection and additionally
> also cannot sender constrain tokens.
>
> The second part of the sta

Re: [OAUTH-WG] Google's use of Implicit Grant Flow

[Dominick Baier]

Well - first of all that it uses all the recommend validation techniques

- state validation + protection
- nonce validation
- at_hash validation
- identity token validation
- discovery

+ solid and tested JS code

I don’t see extra value for a JS client in things like “signed requests” -
as I said before - at the end of the day the access token will end up in
the browser. Regardless how secure you made the authentication request in
the first place.


---
Dominick Baier

On 17 February 2017 at 19:06:23, Jim Manico (j...@manicode.com) wrote:

> Given a solid client library for JS, I think implicit flow is OK to use.

If you can, can you dig deeper here? What is it about this particular
library that makes its use of the OAuth 2 implicit flow secure? Signed
messages? Only supports registered clients? Something else?

Aloha, Jim

On 2/17/17 8:02 AM, Dominick Baier wrote:

Given a solid client library for JS, I think implicit flow is OK to use.

But I agree that there are many “home grown” implementation out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the “pit of success”.

You should give this lib a go (it’s also a certified RP):

https://github.com/IdentityModel/oidc-client-js

Many people argue that handling the protocol and crypto pieces in JS is
problematic (and I agree if no proper lib is used for that) - but at then
end of the day the access token will end up in the browser - and a sloppy
developer (e.g. not using CSP) will always write bad code that might lead
to leaking a token.

---
Dominick Baier

On 17 February 2017 at 18:43:25, Adam Lewis (
adam.le...@motorolasolutions.com) wrote:

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:

> Thank you to those answering my question on implicit for JS clients.
>
> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC use
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clear
> OAuth 2 recommendations for JavaScript client developers?
>
> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>
> Aloha, Jim
>
>
>
> On 2/17/17 6:03 AM, sebastian.ebl...@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> * Von:* OAuth [mailto:oauth-boun...@ietf.org ] *Im
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__keycloak.org&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=YExyuyZO5YNpSvS3mEUG5pjKAjRXXVT8Xvk8hIb-Efw&e=>
>
>
>
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.google.com_identity_protocols_OAuth2UserAgent&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=_Mig-zmCt1y9dZpCece1dqby3VmcZVOu2JPcmAwzwKU&e=>
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
>
> Aloha,
>
> --
>
> Jim Manico
>
> Manicode Security
>
> https://www.manicode.com 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>
&g

Re: [OAUTH-WG] Google's use of Implicit Grant Flow

[Dominick Baier]

Given a solid client library for JS, I think implicit flow is OK to use.

But I agree that there are many “home grown” implementation out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the “pit of success”.

You should give this lib a go (it’s also a certified RP):

https://github.com/IdentityModel/oidc-client-js

Many people argue that handling the protocol and crypto pieces in JS is
problematic (and I agree if no proper lib is used for that) - but at then
end of the day the access token will end up in the browser - and a sloppy
developer (e.g. not using CSP) will always write bad code that might lead
to leaking a token.

---
Dominick Baier

On 17 February 2017 at 18:43:25, Adam Lewis (
adam.le...@motorolasolutions.com) wrote:

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:

> Thank you to those answering my question on implicit for JS clients.
>
> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC use
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clear
> OAuth 2 recommendations for JavaScript client developers?
>
> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>
> Aloha, Jim
>
>
>
> On 2/17/17 6:03 AM, sebastian.ebl...@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> * Von:* OAuth [mailto:oauth-boun...@ietf.org ] *Im
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__keycloak.org&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=YExyuyZO5YNpSvS3mEUG5pjKAjRXXVT8Xvk8hIb-Efw&e=>
>
>
>
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.google.com_identity_protocols_OAuth2UserAgent&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=_Mig-zmCt1y9dZpCece1dqby3VmcZVOu2JPcmAwzwKU&e=>
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
>
> Aloha,
>
> --
>
> Jim Manico
>
> Manicode Security
>
> https://www.manicode.com 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWRUitqM5S1JU&e=>
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWR

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

[Dominick Baier]

The id_token is a validatable protocol response - OAuth on its own cannot 
provide this and i doubt it is worth teaching teaching it new tricks. 

I personally have moved on to always add id_token as a response type - together 
with OIDC discovery, in my mind OIDC is a superset of OAuth and I always use 
them together - or put differently - I recommend against using OAuth on its own 
without OIDC (besides client_creds/extension grants scenarios of course).

— 
cheers
Dominick Baier

On 2 May 2016 at 04:08:25, William Denniss (wdenn...@google.com) wrote:

I'm inclined to think that Nat's comment is right: "As I look at it more and 
more, it started to look like the problem of accepting tainted values without 
message authentication. To fix the root cause, we would have to authenticate 
response. ID Token was designed to also serve as a solution anticipating it."

Even if we workaround the current issue with more unbound plain text params, 
will it solve the next issue?  Personally I'm not convinced.

I also wonder at what level of risk is the right solution "code id_token", 
which the researchers note will mitigate the attacks (when implemented 
correctly).

If we absolutely must solve this without "id_token", I know John has a few 
ideas for lightweight binding of the request & response by hashing the request 
URL and some config. I wonder if a "lightweight crypto" approach is superior to 
"more unbound params" as the best non-id_token option.

On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura  wrote:
It actually depends on what risk level the transaction is at. For low risk 
transactions, just having separate redirection endpoint may be adequate. On the 
other hand, I can easily think of an attack that replaces iss on the authz 
response making the control invalid posing questions on whether it is worth 
introducing it.
On Sun, May 1, 2016 at 14:21 Justin Richer  wrote:
I agree that we’re getting dangerously close to recommending signed assertions 
at every step of the process, thereby bypassing HTTP. This was the same mistake 
that WS-* and SOAP made, let’s not repeat it if we can.

 — Justin

On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt  
wrote:

Hi Nat,

sure, one could also authenticate and cryptographically protect the redirect 
response. Leveraging OIDC concepts is an idea worth considering but they should 
be adopted to the OAuth philosophy. The id token as used in the hybrid flows 
mixes an identity assertion with elements of transport security measures. A 
OAuth AS does not provide identity data to clients, so we only need the 
transport security part.

I personally would prefer a OAuth response object (similar to request object 
you have proposed) over the id token. Such a response object could contain (and 
directly protect) state, code and other response values. I consider this the 
more elegant design and it is easier to implement then having detached 
signatures over hash values of codes or access tokens. Moreover, it would allow 
to encrypt the response as well.

Generally, our threat analysis so far does not have provided justification for 
cryptographically protected redirect responses. All proposals currently on the 
table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its balance of versatility, security 
and _simplicity_. We definitely need to keep it secure, but we should also keep 
it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it started to look like the problem of accepting 
tainted values without message authentication. To fix the root cause, we would 
have to authenticate response. ID Token was designed to also serve as a 
solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt  
wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

__

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries for Android and iOS now available

[Dominick Baier]

I am working on a xplat library for .net/xamarin iOS, Android, WinPhone, 
Windows written in C#.

https://github.com/IdentityModel/IdentityModel.OidcClient

We are making good progress, but the xplat crypto story is the hardest part 
here.

If anybody wants to contribute, contact me via github.

— 
cheers
Dominick Baier

On 1 April 2016 at 00:46:03, Eduardo Gueiros (eguei...@jive.com) wrote:

Any plan to bring the libraries to more “young” languages like Swift in iOS and 
Kotlin in Android?

> On Feb 26, 2016, at 12:30 PM, William Denniss  wrote:
>  
>  

___
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] HTTP signing spec and nonce

[Dominick Baier]

The nonce would allow to build a replay cache, the timestamp to trim that cache 
and reject messages that are too old.

Similar protocols have a nonce for the above reasons (ws-sec msg security, 
hawk)...

— 
cheers
Dominick Baier

On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu) wrote:

I’d be glad to add in a nonce if there’s a compelling reason for it, such as 
closing a security attack vector.

What’s the proposed purpose of the nonce? Is it just to add randomness to the 
signing base? Or is it to prevent replay at the RS? If the former, the 
timestamp should add enough of that and it can be verified to be within a 
reasonable window by the RS by comparing it with the time the request was made. 
If the latter, the RS is going to have to track previously used nonces for some 
amount of time. 

There was a small discussion of just signing an outgoing “Date:” header instead 
of the separate timestamp, but the timestamp seemed to be more robust. I forget 
the full reasoning though.

 — Justin

On Feb 26, 2016, at 9:49 AM, Brock Allen  wrote:

Question about the HTTP signing spec – why is there no nonce (and just a 
timestamp)?
 
TIA
 
-Brock
 
___
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] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

[Dominick Baier]

I also added a support for it to our .NET client library.

blog post here: 
http://leastprivilege.com/2016/02/02/pkce-support-in-identityserver-and-identitymodel/

-- 
Dominick Baier

On 2 February 2016 at 09:25:43, Dominick Baier (dba...@leastprivilege.com) 
wrote:

IdentityServer 2.4 has PKCE support now as well

https://github.com/IdentityServer/IdentityServer3/releases/tag/2.4.0

-- 
Dominick Baier

On 1 February 2016 at 22:12:54, Mike Jones (michael.jo...@microsoft.com) wrote:

Congratulations on your deployment!

 

From: William Denniss [mailto:wdenn...@google.com]
Sent: Monday, February 1, 2016 12:25 PM
To: Mike Jones 
Cc: John Bradley ; Nat Sakimura ; 
oauth@ietf.org
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery 
(draft-jones-oauth-discovery-00)

 

We are now live with this change:

 

https://accounts.google.com/.well-known/openid-configuration

 

I'm glad we all reached a consensus on how this param should work, and what it 
should be called, and thank you Mike for revising the draft! My ask now is that 
we don't revisit this decision, unless for extremely good reasons, as we don't 
want to break clients who will start using this.

 

On Mon, Jan 25, 2016 at 4:08 PM, William Denniss  wrote:

Thanks Mike, looking forward to the update. I reviewed the other thread.

 

On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones  wrote:

I'll add it to the discovery draft in the next day or so.  Also, please see my 
questions in the message "[OAUTH-WG] Discovery document updates planned". I was 
waiting for that feedback before doing the update.

Thanks,
-- Mike

From: William Denniss
Sent: ‎1/‎25/‎2016 2:29 PM
To: John Bradley
Cc: Nat Sakimura; oauth@ietf.org; Mike Jones
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery 
(draft-jones-oauth-discovery-00)

OK great! It seems that we have consensus on this. So this is what we plan to 
add to our discovery doc, based on this discussion:

 

"code_challenge_methods_supported": ["plain","S256"]

 

What are the next steps? Can we we add it to 
https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see that 
the IANA registry created by that draft is "Specification Required", but PKCE 
is already an RFC without this param being registered.

 

 

On Mon, Jan 25, 2016 at 2:11 PM, John Bradley  wrote:

Yes sorry.   code_challenge_method is the query parameter so 
code_challenge_methods_supported

 

 

On Jan 25, 2016, at 6:12 PM, William Denniss  wrote:

 

 

 

On Thu, Jan 21, 2016 at 6:17 AM, John Bradley  wrote:

The code_challenge and code_challenge_method parameter names predate calling 
the spec PKCE.  

 

Given that some of us deployed early versions of PKCE in products and 
opensource to mitigate the problem before the spec was completed we decided not 
to rename the parameter names from code_verifier_method to 
pkce_verifier_method.  

 

For consistency we should stick with code_verifier_methods_supported in 
discovery.

 

To clarify, did you mean "code_challenge_methods_supported"?  That is, building 
on the param name "code_challenge_method" from Section 4.3?

 

 

John B.

 

On Jan 21, 2016, at 3:12 AM, William Denniss  wrote:

 

"code_challenge_methods_supported" definitely works for me.

 

Any objections to moving forward with that? I would like to update our 
discovery doc shortly.

 

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura  wrote:

Ah, OK. That's actually reasonable. 

 

2016年1月21日(木) 9:31 nov matake :

I prefer “code_challenge_methods_supported”, since the registered parameter 
name is “code_challenge_method”, not “pkce_method".

 

On Jan 19, 2016, at 11:58, William Denniss  wrote:

 

Seems like we agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

 

or

 

"pkce_methods_supported": ["plain", "S256"]


 

On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt  
wrote:

+1

 

Am 06.01.2016 um 18:25 schrieb William Denniss:

+1

 

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley  wrote:

Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.

> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov  
> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>

> ___
> 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] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

[Dominick Baier]

IdentityServer 2.4 has PKCE support now as well

https://github.com/IdentityServer/IdentityServer3/releases/tag/2.4.0

-- 
Dominick Baier

On 1 February 2016 at 22:12:54, Mike Jones (michael.jo...@microsoft.com) wrote:

Congratulations on your deployment!

 

From: William Denniss [mailto:wdenn...@google.com]
Sent: Monday, February 1, 2016 12:25 PM
To: Mike Jones 
Cc: John Bradley ; Nat Sakimura ; 
oauth@ietf.org
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery 
(draft-jones-oauth-discovery-00)

 

We are now live with this change:

 

https://accounts.google.com/.well-known/openid-configuration

 

I'm glad we all reached a consensus on how this param should work, and what it 
should be called, and thank you Mike for revising the draft! My ask now is that 
we don't revisit this decision, unless for extremely good reasons, as we don't 
want to break clients who will start using this.

 

On Mon, Jan 25, 2016 at 4:08 PM, William Denniss  wrote:

Thanks Mike, looking forward to the update. I reviewed the other thread.

 

On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones  wrote:

I'll add it to the discovery draft in the next day or so.  Also, please see my 
questions in the message "[OAUTH-WG] Discovery document updates planned". I was 
waiting for that feedback before doing the update.

Thanks,
-- Mike

From: William Denniss
Sent: ‎1/‎25/‎2016 2:29 PM
To: John Bradley
Cc: Nat Sakimura; oauth@ietf.org; Mike Jones
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery 
(draft-jones-oauth-discovery-00)

OK great! It seems that we have consensus on this. So this is what we plan to 
add to our discovery doc, based on this discussion:

 

"code_challenge_methods_supported": ["plain","S256"]

 

What are the next steps? Can we we add it to 
https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see that 
the IANA registry created by that draft is "Specification Required", but PKCE 
is already an RFC without this param being registered.

 

 

On Mon, Jan 25, 2016 at 2:11 PM, John Bradley  wrote:

Yes sorry.   code_challenge_method is the query parameter so 
code_challenge_methods_supported

 

 

On Jan 25, 2016, at 6:12 PM, William Denniss  wrote:

 

 

 

On Thu, Jan 21, 2016 at 6:17 AM, John Bradley  wrote:

The code_challenge and code_challenge_method parameter names predate calling 
the spec PKCE.  

 

Given that some of us deployed early versions of PKCE in products and 
opensource to mitigate the problem before the spec was completed we decided not 
to rename the parameter names from code_verifier_method to 
pkce_verifier_method.  

 

For consistency we should stick with code_verifier_methods_supported in 
discovery.

 

To clarify, did you mean "code_challenge_methods_supported"?  That is, building 
on the param name "code_challenge_method" from Section 4.3?

 

 

John B.

 

On Jan 21, 2016, at 3:12 AM, William Denniss  wrote:

 

"code_challenge_methods_supported" definitely works for me.

 

Any objections to moving forward with that? I would like to update our 
discovery doc shortly.

 

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura  wrote:

Ah, OK. That's actually reasonable. 

 

2016年1月21日(木) 9:31 nov matake :

I prefer “code_challenge_methods_supported”, since the registered parameter 
name is “code_challenge_method”, not “pkce_method".

 

On Jan 19, 2016, at 11:58, William Denniss  wrote:

 

Seems like we agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

 

or

 

"pkce_methods_supported": ["plain", "S256"]


 

On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt  
wrote:

+1

 

Am 06.01.2016 um 18:25 schrieb William Denniss:

+1

 

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley  wrote:

Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.

> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov  
> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>

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

 

___
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] PKCE & Hybrid Flow

[Dominick Baier]

Thanks!

we are almost done implementing PKCE in identity server.

And yea - a comment that PKCE applies to whenever a code is involved would be 
probably helpful for other implementers. Even if that makes total sense, it is 
not obvious.

— 
cheers
Dominick Baier


On 27 January 2016 at 03:11:28, Nat Sakimura (sakim...@gmail.com) wrote:

To the end, perhaps amending RFC6749 so that the response type is treated as a 
space separated value would be a better way to go? 

2016年1月27日(水) 5:20 John Bradley :
Yes it also applies to the “code id_token” response_type.   It would also apply 
to “code token” , “code token id_token” response types as well though I can’t 
think of why a native app would use those.

We can look at a errata to clarify.  It is a artifact of resonse_type being 
treated as a single string as opposed to being space separated values as most 
people would expect.

John B.

On Jan 26, 2016, at 5:11 PM, Dominick Baier  wrote:

Hi, 

PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to OIDC 
hybrid flow e.g. code id_token?

— 
cheers
Dominick Baier

___
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

[OAUTH-WG] PKCE & Hybrid Flow

[Dominick Baier]

Hi, 

PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to OIDC 
hybrid flow e.g. code id_token?

— 
cheers
Dominick Baier

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

Re: [OAUTH-WG] Token introspection for public clients?

[Dominick Baier]

I totally agree with that - and that’s how we gonna implement it in identity 
server.

We are planning to introduce something called a “scope secret” - it’s like a 
client secret but for resources.

— 
cheers
Dominick Baier


On 20 Jul 2015 at 07:01:48, Justin Richer (jric...@mit.edu) wrote:

Because the target isn’t the client, it’s the protected resource. We’re 
re-using OAuth’s client credentialing mechanisms (optionally, you can use 
whatever you deem necessary), but it’s not a client that’s doing it. That’s why 
it was changed to a MUST — there may be public clients out there (which could 
also use RFC7591 to become non-public), but public resource servers don’t make 
nearly as much sense.

Additionally, the discussion for this was back in December during the WGLC, and 
the time for normative changes to this particular spec is largely over at this 
stage.

 — Justin

On Jul 20, 2015, at 12:03 AM, William Denniss  wrote:

I see in earlier drafts that client authentication MUST was a SHOULD.

Why not put it back to a SHOULD, and make these arguments in the Security 
Considerations?  By the sound of it in some implementations there are good 
reasons for doing client authentication, but they may not apply to everyone, so 
do we need to be so prescriptive?  An error response can be added for requests 
the server deems require client authentication.

It wouldn't have to be an all-or-nothing policy choice either, a server could 
chose to reject requests from confidential clients where client authentication 
is not provided, but accept requests without client authentication from 
non-confidential clients.  A server that has sufficiently high entropy in the 
tokens, abuse protection on the endpoint, and is not concerned about an 
unrelated party (that happens to have a token intended for a different party) 
learning the token metadata, could simply not require any client authentication 
at all.

Apart from anything, it is really trivial to support non-confidential client 
usage, so why not?  Perhaps there are some use-cases that will turn up in the 
future (especially since as defined the introspection response is extensible). 
One I can think of now is debugging: it's useful during development to be able 
to inspect the tokens you get back from the AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer  wrote:
In the case of a “public client” using a token, the authorization is the token 
that the resource server uses to call the introspection endpoint, along side 
the token that it is introspecting. This is exactly how the UMA protocol works: 
the resource server has a “Protection API Token” that it uses to call several 
endpoints at the AS, including the introspection endpoint. In UMA, this PAT is 
given to the resource server through a normal OAuth transaction with an end 
user who facilitates the RS->AS introduction.

And I think this is all actually a moot point because clients shouldn’t be 
doing the introspection in the first place — the whole spec is there to support 
resource servers introspecting at the auth server. So you probably don’t have 
“public client resource servers” out there. We simply re-used OAuth’s existing 
client authentication mechanism, that doesn’t make them clients. This decision 
is based on development and deployment experience (as in, several people 
independently built it exactly this way). Do you have a use case where you’ve 
got a protected resource that can’t hold credentials (either a client secret or 
a public/private keypair) to authenticate with, and can’t be introduced using 
OAuth to the AS as in UMA?

To your other point: An attacker has less of a chance of getting information 
about a token by fishing at a protected resource with tokens, since they’re not 
being returned information about the token other than the fact that the token 
worked. (Or at least it seemed to work because a result came back — you could 
easily give a suspected attacker valid-looking-but-fake data as one mitigation 
mechanism.) The introspection response can give you information about where 
else the token could be used, potentially. Additionally, the RS really ought to 
be preventing data-fishing attacks like this just for its own sake anyway. 
There are lots of techniques for doing this, but they tend to be specific to 
the kind of API that’s being served.

Requiring the resource server to authenticate with the authorization server 
also allows you to do a few other useful things. Our implementation, for 
example, limits the token information that is returned to a particular AS. This 
allows us to have tokens that can be used in multiple RS’s without those RS’s 
ever even knowing the token is powerful enough to be used elsewhere. It 
prevents information about the authorization from leaking to parties who have 
no business knowing.

Hope this helps clarify it,
 — Justin

On Jul 19, 2015, at 7:59 PM, Aaron Parecki  wrote:

How are public clients supposed to au