Re: [OAUTH-WG] WGLC for Browser-based Apps

[Jim Manico]

I think, by far, Philippe’s perspective on web security and the threat modeling 
of BFF vs SPA based implicit flows is accurate and astute.

His perspective should be the driving force for any standard in this area.

I also think it’s dangerous misinformation to claim that BFF has no security 
benefits.

Thanks all,
--
Jim Manico
@Manicode
Secure Coding Education

> On Aug 28, 2023, at 8:15 AM, Jim Manico  wrote:
> 
> *applause*
> 
> Sucks you need to explain yourself several times but this is very helpful for 
> the community.
> 
>>> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck 
>>>  wrote:
>>> 
>> Responses inline.
>> 
>>> Still, there is some initial incorrect point that makes the rest of the 
>>> discussion complicated, and partly wrong.
>> 
>> I believe the key to make the discussion less complicated is to acknowledge 
>> that there are two separate issues:
>> 
>> 1. An attacker can potentially obtain tokens from the legitimate application
>> 2. An attacker can obtain a set of tokens from the AS directly, completely 
>> independent of any application behavior
>> 
>> Given that the goal is to prevent an attacker from obtaining tokens, 
>> scenario 1 becomes irrelevant when scenario 2 is a possibility. It would be 
>> really helpful to analyze the SW approach with this in mind. I’ll add 
>> comments inline to highlight why this matters.
>> 
>>> 
>>> Specifically, §6.4.2.1 says this: The service worker MUST NOT transmit 
>>> tokens, authorization codes or PKCE code verifier to the frontend 
>>> application.
>>> 
>>> Wording should be refined, but the idea is that the service worker is to 
>>> actually restrict authorization codes from even reaching the frontend. Of 
>>> course, easier said than done, but that part happens to be quite easy to 
>>> implement. 
>> 
>> This is related to both scenarios. If the SW is running, you can indeed hide 
>> tokens from the main browsing context, which helps to support scenario 1. 
>> For scenario 2, you need the guarantee that the SW will intercept all new 
>> flows, otherwise the attacker  can run a silent flow. As long as the SW is 
>> running in the main context, I would assume that the attacker can indeed not 
>> reach the authorization endpoint directly. 
>> 
>> The key part above is “as long as the SW is running”. An attacker with the 
>> ability to run malicious JS can unregister the SW that prevents the attacker 
>> from reaching the authorization endpoint. 
>> 
>> I have raised this issue before, and the response back then was that the SW 
>> is only actually removed after the browsing context reloads, which is true. 
>> So from the main context, the attacker cannot launch the attack. However, 
>> when the attacker instantiates a new browsing context (i.e., an iframe), the 
>> unregistered SW is no longer present, and is thereby not able to restrict 
>> access to the authorization endpoint. 
>> 
>> I address this concern in the talk I have referenced before. This link with 
>> the time code included (https://youtu.be/OpFN6gmct8c?feature=shared=1973) 
>> points you to the exact demo scenario, where I illustrate how an 
>> unregistered SW cannot prevent access to an endpoint in an iframe. 
>> Admittedly, I have not implemented a full OAuth client as a SW, but the 
>> minimal PoC you see here suffices to illustrate the ineffectiveness of this 
>> approach.
>> 
>> With this information, the attack scenario becomes the following:
>> The attacker unregisters the SW in the main browsing context, preventing it 
>> from being used in any new browsing context
>> The attacker injects a new iframe and points it to the authorization endpoint
>> The AS responds with a redirect with the authorization code
>> The attacker detects the redirect, copies the authorization code, and aborts 
>> the page from loading (so that the authorization code is never exchanged or 
>> the SW is never reloaded)
>> The attacker extracts the authorization code and exchanges it for tokens
>> 
>> 
>> TL;DR: a SW is not a security mechanism, and the browser cannot guarantee 
>> that a SW permanently prevents requests to a certain endpoint.
>> 
>> 
>>> This has further impact on much of the other statements:
>>> > The main problem with a browser-only client is that the attacker with 
>>> > control over the client has the ability to run a silent Authorization 
>>> > Code flow, which provides them with an independent set of tokens
>>> [...]
>>> > The 

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Jim Manico]

*applause*

Sucks you need to explain yourself several times but this is very helpful for 
the community.

> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck 
>  wrote:
> 
> Responses inline.
> 
>> Still, there is some initial incorrect point that makes the rest of the 
>> discussion complicated, and partly wrong.
> 
> I believe the key to make the discussion less complicated is to acknowledge 
> that there are two separate issues:
> 
> 1. An attacker can potentially obtain tokens from the legitimate application
> 2. An attacker can obtain a set of tokens from the AS directly, completely 
> independent of any application behavior
> 
> Given that the goal is to prevent an attacker from obtaining tokens, scenario 
> 1 becomes irrelevant when scenario 2 is a possibility. It would be really 
> helpful to analyze the SW approach with this in mind. I’ll add comments 
> inline to highlight why this matters.
> 
>> 
>> Specifically, §6.4.2.1 says this: The service worker MUST NOT transmit 
>> tokens, authorization codes or PKCE code verifier to the frontend 
>> application.
>> 
>> Wording should be refined, but the idea is that the service worker is to 
>> actually restrict authorization codes from even reaching the frontend. Of 
>> course, easier said than done, but that part happens to be quite easy to 
>> implement. 
> 
> This is related to both scenarios. If the SW is running, you can indeed hide 
> tokens from the main browsing context, which helps to support scenario 1. For 
> scenario 2, you need the guarantee that the SW will intercept all new flows, 
> otherwise the attacker  can run a silent flow. As long as the SW is running 
> in the main context, I would assume that the attacker can indeed not reach 
> the authorization endpoint directly. 
> 
> The key part above is “as long as the SW is running”. An attacker with the 
> ability to run malicious JS can unregister the SW that prevents the attacker 
> from reaching the authorization endpoint. 
> 
> I have raised this issue before, and the response back then was that the SW 
> is only actually removed after the browsing context reloads, which is true. 
> So from the main context, the attacker cannot launch the attack. However, 
> when the attacker instantiates a new browsing context (i.e., an iframe), the 
> unregistered SW is no longer present, and is thereby not able to restrict 
> access to the authorization endpoint. 
> 
> I address this concern in the talk I have referenced before. This link with 
> the time code included (https://youtu.be/OpFN6gmct8c?feature=shared=1973) 
> points you to the exact demo scenario, where I illustrate how an unregistered 
> SW cannot prevent access to an endpoint in an iframe. Admittedly, I have not 
> implemented a full OAuth client as a SW, but the minimal PoC you see here 
> suffices to illustrate the ineffectiveness of this approach.
> 
> With this information, the attack scenario becomes the following:
> The attacker unregisters the SW in the main browsing context, preventing it 
> from being used in any new browsing context
> The attacker injects a new iframe and points it to the authorization endpoint
> The AS responds with a redirect with the authorization code
> The attacker detects the redirect, copies the authorization code, and aborts 
> the page from loading (so that the authorization code is never exchanged or 
> the SW is never reloaded)
> The attacker extracts the authorization code and exchanges it for tokens
> 
> 
> TL;DR: a SW is not a security mechanism, and the browser cannot guarantee 
> that a SW permanently prevents requests to a certain endpoint.
> 
> 
>> This has further impact on much of the other statements:
>> > The main problem with a browser-only client is that the attacker with 
>> > control over the client has the ability to run a silent Authorization Code 
>> > flow, which provides them with an independent set of tokens
>> [...]
>> > The security differences between a BFF and a browser-only app are not 
>> > about token storage, but about the attacker being able to run a new flow 
>> > to obtain tokens.
>> [...]
>> > Again, the security benefits of a BFF are not about stoken storage. Even 
>> > if you find the perfect storage solution for non-extractable tokens in the 
>> > browser, an attacker still controls the client application and can simply 
>> > request a new set of tokens. 
>> 
>> Truth is: no, you can't start a new authentication flow and get the 
>> authorization code back in the main thread. I'm talking about the 
>> redirection scenario, which I'm the most familiar with, but it would 
>> probably apply to the "message" one as well (which is new to me and seems to 
>> be ashtoningly legit due to vague "for example" wording in the OAuth2 spec 
>> :-) ).
> 
> The attack scenario above does not run the redirect scenario in the main 
> browsing context, but in an iframe. Opening an iframe instantiates a new 
> nested browsing context, where unregistered SWs are not available. 
> 

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Jim Manico]

> We can either expand on that nuance, or more simply switch the SHOULD to MAY so that we inform the reader of what it takes to support (a style of SPA) but we don't appear to be advocating for the less secure option.I would argue that BFF is radically more secure and the SHOULD should remain or even move to a MUST. Storing high powered access tokens in a browser is significantly insecure in the face of XSS which very (very) few applications control well, especially ones that are complex enough to need OAuth2.--Jim Manico@ManicodeOn Mar 9, 2023, at 3:30 AM, Warren Parad  wrote:It requires third party cookies which most browsers block by default, and doesn't this assume that the cookie is set to SameSite=Loose or SameSite=None. Wouldn't that directly expose that cookie for malicious sites to utilize it to steal connect2Id generate access tokens?Also what I don't understand from the connect2id site is:Performing the redirection in a hidden iframe doesn't normally work for an SPA either.Why does it say that? (I feel like it drops this little bomb in there and then runs away. maybe there is a specific reason, but if there is it is lost on me)On Thu, Mar 9, 2023 at 12:13 PM Dmitry Telegin 40backbase@dmarc.ietf.org> wrote:Hi all,In regards to the use cases for CORS in the Authorization endpoint - what about a SPA requesting a step-up reauthentication? Especially if it is "silent", e.g. initiating out-of-band authentication without the need for user interaction. Currently, we don't have too many options; it's either a full redirect + app reload (not so good from the UX point of view) or a (hidden) iframe. Probably deserves a separate discussion?On a related note, Connect2ID seems to be the only IAM solution that offers limited support for CORS in the Authorization endpoint (prompt=none + response_mode=cors). The use case they're supporting is silent refresh in the absence of a long-lived refresh token. See link: https://connect2id.com/products/server/docs/guides/cors-response-modeAlso, it has been mentioned that "CORS on the authorization endpoint is a security issue" - could we elaborate on that? What would be the ramifications of having it?Cheers,DmitryOn Thu, Mar 9, 2023 at 9:23 AM Filip Skokan <panva...@gmail.com> wrote:Hello Christopher,The wmrm specification use does not require CORS at the authorization endpoint. - Filip9. 3. 2023 v 10:12, Christopher Burroughs 40protonmail...@dmarc.ietf.org>:Greetings,I apologize in advance if this question (my first in this list!) is silly :)Regarding CORS support for the authorization endpoint, what about "web message" silent refresh flows? While it never became an RFC, I reckon it is implemented in quite a few places. Is this pattern generally discouraged now? Perhaps even more due to the unavailability of same site cookies?Thanks for the interesting discussions, Best regards,Chris






Sent with Proton Mail secure email.



--- Original Message ---
On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci 40auth0@dmarc.ietf.org> wrote:

Ha, we chatted about this during yesterday's office hours meeting and I was chartered to propose new language, but I am not sure how to incorporate this new info. Let me try to summarize here and see your reactions, DW.Apps implemented in SPAs style can either handle token acquisition and renewal from the user agent code, via classic authorization code + PKCE, or delegate that to a backend (BFF or "TMI BFF") while retaining "SPA style" for every other app function (eg UX). CORS is required only for the former approach, and one could argue that the latter offers better security.We can either expand on that nuance, or more simply switch the SHOULD to MAY so that we inform the reader of what it takes to support (a style of SPA) but we don't appear to be advocating for the less secure option.On CORS for the authorization endpoint. I thought the MUST NOT was aimed at preventing programmatic access to the authorization endpoint from user agents. Flipping around: are there any other scenarios involving the authorization endpoint for which CORS support enables valid use cases? On Wed, Mar 8, 2023 at 10:50 AM David Waite 40alkaline-solutions@dmarc.ietf.org> wrote:

This message originated outside your organization.
  
I would suggest SHOULD guidance for CORS for OAuth token endpoints and authorization endpoints which are publicly accessible.There are a lot of misconceptions about the security properties of CORS, and in particular the security properties from disabling CORS for an otherwise safe resource. To my knowledge there is one benefit of disabling for solely internally-facing infrastructure.To detail, a public website interacting with a user agent bridging public and private networks can use IPs and DNS to attempt to scan internal web infrastructure. It may attemp

Re: [OAUTH-WG] proof of access token possession using client secret

[Jim Manico]

> I would like to prevent clients from sharing their access tokens. I 
am wondering if requiring clients to include the "client secret" in the 
resource access request (in addition to the access token) is a valid 
strategy.


Sender-constrained access tokens are suggested in the current security 
best practice guide here. 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.2


So yes!

- Jim Manico

On 3/2/22 8:18 AM, Warren Parad wrote:
Is there a reason you wouldn't want to use the access token to access 
these resources? That seems like it would be the optimal strategy.




Warren Parad

Founder, CTO

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



On Wed, Mar 2, 2022 at 4:58 PM Nikos Fotiou  wrote:

Hi all,

I am working on a use case where the Authorization Server and the
Resource Server are the same entity. I would like to prevent
clients from sharing their access tokens. I am wondering if
requiring clients to include the "client secret" in the resource
access request (in addition to the access token) is a valid
strategy. This way clients would have to share their "client
secret" in addition to the access token. Would that work?

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

___
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


--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web apps BCP feedback

[Jim Manico]

> That’s why cookies should be set with the __Host- prefix. 

You can also set the domain of a cookie to actually be a host (subdomain). Does 
that also prevent subdomains from clobbering root directory cookies?

PS: I realize this is close to off topic, my last comment on this.

- Jim Manico


> On Sep 25, 2021, at 10:24 PM, Neil Madden  wrote:
> 
> 
> Right, cookie prefixes is one approach - but still has a little way to go on 
> browser share [1]. 
> 
> In my book (have I mentioned my book? :-)), I show a variant of the 
> double-submit cookie pattern in which the anti-CSRF token is a SHA-256 hash 
> of the session cookie [2], which prevents the cookie being overridden.
> 
> We should probably just defer to the security considerations in rfc6265-bis 
> [3], which already discusses some limitations of SameSite and recommends it 
> be used as a defence-in-depth alongside traditional defences. 
> 
> [1]: https://caniuse.com/?search=cookie%20prefix
> [2]: https://livebook.manning.com/book/api-security-in-action/chapter-4/181
> [3]: 
> https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-08.html#name-samesite-cookies
> 
> — Neil
> 
>>> On 26 Sep 2021, at 07:30, Philippe De Ryck 
>>>  wrote:
>>> 
>> That’s why cookies should be set with the __Host- prefix. 
>> 
>> In a carefully-designed API, CORS will function as a CSRF defense, even when 
>> the attacker is controlling a subdomain or sibling domain. 
>> 
>> Overall, I think the first part of 6.1 makes sense, but I don’t think the 
>> document should try to draw out such an architecture in 1 or 2 paragraphs at 
>> the end of that section.
>> 
>> Philippe
>> 
>> —
>> Pragmatic Web Security
>> Security for developers
>> https://pragmaticwebsecurity.com
>> 
>>> On 26 Sep 2021, at 00:15, Jim Manico  wrote:
>>> 
>>> Hi Neil! =)
>>> 
>>> I get your point! 
>>> I would suggest this text be written as something along the lines of:
>>> 
>>> "Additionally, the SameSite cookie attribute can be used to 
>>>prevent CSRF attacks but the application and API should  also
>>>be written to use anti-CSRF tokens for stateful session-based 
>>> applications 
>>>   or use of the double-cookie submit pattern for stateless 
>>> applications.”'
>>> 
>>> PS: If an adversary controls a subdomain can't they clobber and over-write 
>>> root level cookies anyhow? I do not think CSRF defense will defeat an 
>>> adversarial subdomains ability to over-write a cookie and circumvent 
>>> double-cookie-submit. 
>>> 
>>>> On 9/25/21 8:10 AM, Neil Madden wrote:
>>>> Technically yes, CSRF refers to cross-site attacks. However, there is a 
>>>> class of attacks that are cross-*origin* but not cross-site and which are 
>>>> otherwise identical to CSRF. SameSite doesn’t protect against these 
>>>> attacks but other traditional CSRF defences *do*. For example, 
>>>> synchronizer tokens in hidden form fields or even just requiring a custom 
>>>> header on requests both provide some protection against such attacks, as 
>>>> they both use mechanisms that are subject to the same origin policy rather 
>>>> than same-site. 
>>>> 
>>>> — Neil
>>>> 
>>>>>> On 25 Sep 2021, at 18:20, Jim Manico  wrote:
>>>>>> 
>>>>>  If someone has taken over a subdomain in the ways described, that is 
>>>>> not cross site request forgery since the attack is occurring from within 
>>>>> your site. It’s more likely XSS that allows for cookie clobbering or 
>>>>> similar, or just malicious code injected by the malicious controller of 
>>>>> your subdomain. This is not strictly CSRF nor are these problems 
>>>>> protected from any other standard form of CSRF defense.
>>>>> 
>>>>> CSRF is Cross Site attack where the attack is hosted on a different 
>>>>> domain. 
>>>>> 
>>>>> --
>>>>> Jim Manico
>>>>> 
>>>>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier  
>>>>>>> wrote:
>>>>>>> 
>>>>>> 
>>>>>> In 6.1 it says
>>>>>> 
>>>>>> "Additionally, the SameSite cookie attribute can be used to  
>>>>>> prevent CSRF attacks, or alternatively, the application and 
>&g

Re: [OAUTH-WG] Web apps BCP feedback

[Jim Manico]

Hi Neil! =)

I get your point!

I would suggest this text be written as something along the lines of:

"Additionally, the SameSite cookie attribute can be used to
  prevent CSRF attacks /*but the application and API should*//*also*/
/**//**//*  be written to use */anti-CSRF tokens for stateful 
session-based applications
  or use of the double-cookie submit pattern for stateless 
applications.”'


PS: If an adversary controls a subdomain can't they clobber and 
over-write root level cookies anyhow? I do not think CSRF defense will 
defeat an adversarial subdomains ability to over-write a cookie and 
circumvent double-cookie-submit.


On 9/25/21 8:10 AM, Neil Madden wrote:
Technically yes, CSRF refers to cross-site attacks. However, there is 
a class of attacks that are cross-*origin* but not cross-site and 
which are otherwise identical to CSRF. SameSite doesn’t protect 
against these attacks but other traditional CSRF defences *do*. For 
example, synchronizer tokens in hidden form fields or even just 
requiring a custom header on requests both provide some protection 
against such attacks, as they both use mechanisms that are subject to 
the same origin policy rather than same-site.


— Neil


On 25 Sep 2021, at 18:20, Jim Manico  wrote:

 If someone has taken over a subdomain in the ways described, that 
is not cross site request forgery since the attack is occurring from 
within your site. It’s more likely XSS that allows for cookie 
clobbering or similar, or just malicious code injected by the 
malicious controller of your subdomain. This is not strictly CSRF nor 
are these problems protected from any other standard form of CSRF 
defense.


CSRF is Cross Site attack where the attack is hosted on a different 
domain.


--
Jim Manico

On Sep 25, 2021, at 1:07 AM, Dominick Baier 
 wrote:



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

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


Manage My Preferences <https://preferences.forgerock.com/>, 
Unsubscribe <https://preferences.forgerock.com/>



--
Jim Manico
Manicode Security
https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web apps BCP feedback

[Jim Manico]

If someone has taken over a subdomain in the ways described, that is not cross 
site request forgery since the attack is occurring from within your site. It’s 
more likely XSS that allows for cookie clobbering or similar, or just malicious 
code injected by the malicious controller of your subdomain. This is not 
strictly CSRF nor are these problems protected from any other standard form of 
CSRF defense.

CSRF is Cross Site attack where the attack is hosted on a different domain. 

--
Jim Manico

> On Sep 25, 2021, at 1:07 AM, Dominick Baier  wrote:
> 
> 
> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - TMI BFF

[Jim Manico]

+1 Mr. Hardt. BFF aims to avoid access tokens in UA's so TMI-BFF is a 
badly branded name that will add confusion.


- Jim

On 5/4/21 11:25 AM, Dick Hardt wrote:
My concern with BFF is that the common meaning is what the document 
calls Full BFF -- so what many readers will assume is BFF is not what 
the document is referring to.

ᐧ

On Tue, May 4, 2021 at 8:03 AM Aaron Parecki <mailto:aa...@parecki.com>> wrote:


I support adoption. I'm also fine with the BFF acronym since it's
common in the software development world already. If anything, the
TMI acronym is the least strong of the two as it's missing a
letter from the full name of the draft.

Aaron




On Tue, May 4, 2021 at 7:40 AM Dick Hardt mailto:dick.ha...@gmail.com>> wrote:

I'm supportive -- but am concerned with the BFF acronym.
ᐧ

On Mon, May 3, 2021 at 3:00 PM Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> wrote:

All,

This is a call for adoption for the *Token Mediating and
Session Information Backend for Frontend* as a WG document:
https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
<https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/>

Please, provide your feedback on the mailing list by *May
17th*.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

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

-- 
---

Aaron Parecki
https://aaronparecki.com <https://aaronparecki.com>


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


--
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] Assessing the negative effects of proposed standards

[Jim Manico]

Vittorio,

I feel you are conflating OIDC with OAuth2. In delegation workflows, the 
AS/RS can be any company and the clients are approved registered 
clients. I use OAuth2 for many of my own consumer needs and there is an 
even distribution of use among many services. OAuth2 protects me. I no 
longer have to hand out my twitter credentials just because my 
conference website wants limited access to my twitter account. I can now 
give my conference website limited delagated access to my twitter 
account and cancel that relationship any time. For years I was forced to 
give up my banking credentials to services like Mint and that is no 
longer the case due to the OAuth2 financial extension (FAPI).


While OIDC is certainly centralizing identity to a few providers, a real 
problem, OAuth2 when used for delegation purposes does not have that 
same inherent risk.


Respectfully,

- Jim Manico


On 3/1/21 9:59 AM, Vittorio Bertola wrote:



Il 01/03/2021 15:13 Jim Manico  ha scritto:


How does OAuth harm privacy? 

I think you are analyzing the matter at a different level.

If you start from a situation in which everyone is managing their own 
online identity and credentials, and end up in a situation in which a 
set of very few big companies (essentially Google, Apple and Facebook) 
are supplying and managing everyone's online credentials and logins, 
then [the deployment of] OAuth[-based public identity systems] is 
harming privacy.


Centralization is an inherent privacy risk. If you securely and 
privately deliver your personal information to parties that can 
monetize, track and aggregate it at scale, then you are losing privacy.


--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com  <mailto:vittorio.bert...@open-xchange.com>  
Office @ Via Treviso 12, 10144 Torino, Italy


--
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] How does OAuth harm privacy ?

[Jim Manico]

Denis,

> With OAuth, the RS must have a prior relationship with the AS (which 
is not scalable).


I do not see this as a real problem since in almost every use case the 
RS and AS are the same provider. If they are not the same provider I 
would suggest federation (OIDC) as opposed to delegation (OAuth2) which 
are completely different standards even though they are built on top of 
the same framework.


> When the client calls the AS, the AS is able to know which is the RS 
and then is in a position to know which end-user is likely to access 
which RS.


If you are using OAuth2 for delegation and the RS and AS are not the 
same provider then I feel you are using the wrong standard/framework.


> When furthermore *token introspection* is being used

Token introspection in my opinion needs to go away. First of all it 
kills performance. It also leaks unnecessary information as you 
rightfully point out. I prefer to migrate to JWT's for this purpose and 
distribute public keys for services that need to verify tokens. Again, 
the  token introspection defeats the point of statelessness, a critical 
feature of modern services.


> Since the access tokens are considered to be opaque to the clients 
(and hence to the end-users), a client is not supposed
to verify which privileges have effectively been inserted into an access 
token, in particular whether a unique identifier
that would allow the RSs to correlate the accounts of their users has 
been maliciously added into every access token.


In typical OAuth2 delegation flows, the user is agreeing to give a 
client a certain level of access to their account at the AS/RS provider. 
The user allows this. The user is saying I am giving ClientX access to 
features A, B and C in my account. Of course the client needs to see 
this in order to effectively communicate to the RS/AS provider. I do not 
see this as a problem. The user is specifically allowing it.


Denis, please keep going. I am not a top tier expert I am still 
learning. I would love to keep this conversation going.


Respectfully,

- Jim Manico


On 3/1/21 10:29 AM, Denis wrote:

Hello Jim,

Since you dared to raise the question: "*How does OAuth harm privacy* 
?", I need to respond. I changed the tile of the thread accordingly.


With OAuth, the RS must have a prior relationship with the AS (which 
is not scalable). When the client calls the AS,
the AS is able to know which is the RS and then is in a position to 
know which end-user is likely to access which RS.


When furthermore *token introspection* is being used, the AS is in a 
position to know exactly when an end-user
is performing an access to every RS. Some people would say that the AS 
is able to act as *Big Brother*.
While this might be acceptable within a single domain (i.e. all the 
users, ASs and RSs belong to the same organization
or company), this is a serious concern if/when used in general over 
the Internet in a multi-domain case.


Since the access tokens are considered to be opaque to the clients 
(and hence to the end-users), a client is not supposed
to verify which privileges have effectively been inserted into an 
access token, in particular whether a unique identifier
that would allow the RSs to correlate the accounts of their users has 
been maliciously added into every access token.


In your email you wrote:

I don’t see how moving from handing your creds over to a third
party to OAuth2 workflows, harms either privacy or security.

I hope that the facts mentioned above will allow you to see that OAuth 
does harm the user's privacy.


Denis




Il 01/03/2021 15:13 Jim Manico  ha scritto:


How does OAuth harm privacy? 

I think you are analyzing the matter at a different level.

If you start from a situation in which everyone is managing their own 
online identity and credentials, and end up in a situation in which a 
set of very few big companies (essentially Google, Apple and 
Facebook) are supplying and managing everyone's online credentials 
and logins, then [the deployment of] OAuth[-based public identity 
systems] is harming privacy.


Centralization is an inherent privacy risk. If you securely and 
privately deliver your personal information to parties that can 
monetize, track and aggregate it at scale, then you are losing privacy.


--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com  <mailto:vittorio.bert...@open-xchange.com>  
Office @ Via Treviso 12, 10144 Torino, Italy


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




--
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] Assessing the negative effects of proposed standards

[Jim Manico]

How does OAuth harm privacy? This critical delegation use case is user driven, 
protects leaking user passwords to third party services, limits access to user 
account features and allows the user to cancel this relationship at any time?

OAuth2 provides more security and privacy than the previous solutions pre-OAuth 
which was to hand your Twitter credentials (or similar) to a third party 
service (OAuth clients) exposing your entire account, permanently, to OAuth 
clients.

OAuth2 radically improves upon this needed web functionality. I don’t see how 
moving from handing your creds over to a third party to OAuth2 workflows, harms 
either privacy or security. It improves upon them both.

Also, OAuth2 is hard. It’s a complicated protocol. Delegation is tough. But 
luckily most developers just need a basic understanding and proper utilization 
of third party libraries for this need and the ecosystem is is getting much 
better. For example, PKCE is now integrated into most OAuth libraries.

I advise this working group to take a class or two (as a group, together) from 
the experts here such as Dr. De Ryck and others so we are all on the same page 
about what modern OAuth2 solutions really look like and what the OAuth2 
framework/protocol actually is.

I am not being combative or trying to hurt anyone when I say that I feel many 
of the commenters here do not understand the details of OAuth2 and what it’s 
for.

--
Jim Manico
@Manicode


> On Mar 1, 2021, at 6:10 AM, Andrew Campling  
> wrote:
> 
> 
> On 01/03/2021 10:44 Vittorio Bertola  
> wrote:
>  
> > Il 26/02/2021 17:32 Aaron Parecki  ha scritto:
>  
>  
> >> Dynamic client registration does exist in OAuth: 
> >> https://tools.ietf.org/html/rfc7591
>  
> >> The point is that basically nobody uses it because they don't want to 
> >> allow arbitrary client registration at their ASs. That's likely due to a 
> >> combination of pre-registration being the default model in OAuth for so 
> >> long (the Dynamic Client Registration draft was published several years 
> >> after OAuth 2.0), as well as how large corporations have decided to run 
> >> their ASs where they want to have (what feels like) more control over the 
> >> things talking to their servers.
>  
> > This is indeed a matter of product design. I am active in an OIDC-based 
> > open identity project where the specs say that providers MUST accept 
> > dynamic client registration, without a pre-determined client secret. This 
> > is the only way to create a federation that can work on an Internet scale, 
> > with relying parties accepting identities managed by providers unknown to 
> > them. Then, of course, this also creates lots of opportunities for abuse: 
> > you end up in an email-like scenario in which you need ways to ascertain 
> > trust in unknown parties and decide whether you want to accept 
> > interoperating with them and believe the information they provide, which in 
> > turn depends a lot on your specific use case. But we think that that is 
> > preferrable to the centralization that is inherent in the original 
> > registration model.
>  
>  
> I wonder whether proposed standards should be assessed for their negative 
> properties, eg whether they are likely to exacerbate centralisation, much 
> like security aspects are reviewed.  It may be that a given proposal might 
> still go forward as the trade-offs are deemed worthwhile, however, they would 
> at least be understood and, ideally, documented.  At present there seems to 
> be an exorable drift towards centralisation which, in my view, has a 
> detrimental impact on both resilience and privacy.  Such developments may 
> satisfy the needs of their proponents but are unlikely to be in the long-term 
> interests of end-users (RFC 8890) and, therefore, it would be helpful if this 
> trend wasn’t made worse by the introduction of new standards.
>  
>  
> Andrew Campling
> ___
> 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] Diversity and Inclusiveness in the IETF

[Jim Manico]

I think it’s important to point out that OAuth is not an authentication 
protocol. It’s for delegation. OAuth is one of the most mis-used protocols on 
the modern web. If you really want to support end users, a good place to start 
is to make it clear to developers what OAuth is really for so secure solutions 
are built as opposed to the dumpster fire that OAuth solutions have become 
today.

Regards,
--
Jim Manico
@Manicode
Secure Coding Education

> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker  
> wrote:
> 
> 
> I am worried by the advice 'use OAUTH' but for a very different reason.
> 
> OAUTH and SAML are both attempts to provide a secure authentication scheme 
> that works within the very particular and very peculiar environment of Web 
> browsers. They are schemes that necessarily involve techniques that are 
> rightly regarded as alchemy if not outright witchcraft.
> 
> That is fine, that is more than fine if you are developing an authentication 
> scheme for use within Web browsers (or if you are developing whatever SAML 
> and OAUTH are these days, neither was originally billed as authentication). 
> But it is completely inappropriate to ever suggest let alone demand that 
> anyone use a technology whose primary design constraint is to work around the 
> voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where 
> none of those legacy issues apply.
> 
> One of the big problems of IETF is that a lot of people don't think about how 
> to get their scheme deployed and when they do, their plan is to tie it to 
> some other group as a boat anchor. Back when we were doing DKIM and SPF we 
> had to tell certain DNS folk that the fact that almost no DNS Registrars 
> offered customers the ability to specify new RRTypes was their problem and 
> was going to remain their problem no matter how loudly they tried to complain 
> that it should become our problem. 
> 
> In the case of OAUTH, there is another problem in that OAUTH really isn't a 
> very open protocol from the standpoint of the user. I can use my Google or my 
> Facebook or my Twitter accounts to log in via OAUTH at a large number of 
> sites. But if I want to use any other OAUTH provider I am completely out of 
> luck. Or at least I will be until this becomes one of the multifaceted 
> complaints in the anti-trust hearings coming soon to a capitol hill near you. 
> And yes, that is a consequence of how the protocol has been deployed, but 
> that probably not going to get people very far on capitol hill.
> 
> 
> The Internet is for everyone. The Internet is for end users.
> 
> I am really not that interested in who makes the ingredients except to the 
> extent that it determines what sort of cake emerges. One of the unexpected 
> side effects of Web 2.0 has been that it has greatly centralized power in the 
> hands of a tiny number of individuals. Individuals who are at best 
> accountable to shareholders, but in the case of some of them, a separate 
> share class ensures that they are accountable to nobody. In neither case are 
> the people with power accountable to end users because they are not even 
> customers, they are the product.
> 
> What I am interested in is the extent to which Internet technologies are 
> Technologies of Freedom. The question we need to ask ourselves is 'does this 
> technology increase end user autonomy or increase their reliance on third 
> parties'.
> ___
> 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] DPoP followup I: freshness and coverage of signature

[Jim Manico]

Brian,

I just focus on web security and understand the risk of XSS well. It 
seems to me that many of the designers of OAuth 2 do not have a web 
security background and keep trying to address XSS with add-ons without 
success.


- Jim

On 12/11/20 2:01 PM, Brian Campbell wrote:

I think that puts Jim in the XSS Nihilism camp :)

Implicit type flows are being deprecated/discouraged. But keeping 
tokens out of browsers doesn't seem likely. There is some menton of 
CSP in 
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7 
<https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7> 



On Wed, Dec 9, 2020 at 4:10 PM Jim Manico <mailto:j...@manicode.com>> wrote:


The basic theme from the web attacker community is:

1) XSS is a game over event to web clients. XSS can steal or abuse
(request forgery) tokens, and more.

2) Even if you prevent stolen tokens from being used outside of a
web client, XSS still allows the attacker to force a user to make
any request in a fraudulent way, abusing browser based tokens as a
form of request forgery.

3) There are advanced measures to stop a token from being stolen
from a web client, like a HTTPonly cookies and to a lesser degree,
JS Closures and Webworkers.

4) However, these measures to protect cookies are mostly moot.
Attackers can just force clients to make fraudulent requests.

5) Many recommend the BFF pattern to hide tokens on the back end,
but still, request forgery via XSS allows all kinds of abuse.

XSS is game over no matter how you slice it.

Crypto solutions do not help. Perhaps the world of OAuth can start
suggesting that web clients use CSP 3.0 in specific ways, if you
still plan to support Implicit type flows or tokens in browsers?

Respectfully,

- Jim


On 12/9/20 12:57 PM, Brian Campbell wrote:

Thanks Philippe, I very much concur with your line of reasoning
and the important considerations. The scenario I was thinking of
is: browser based client where XSS is used to exfiltrate the
refresh token along with pre-computed proofs that would allow for
the RT to be exchanged for new access tokens and also
pre-computed proofs that would work with those access tokens for
resource access. With the pre-computed proofs that would allow
prolonged (as long as the RT is valid) access to protected
resources even when the victim is offline. Is that a concrete
attack scenario? I mean, kind of. It's pretty convoluted/complex.
And while an access token hash would reign it in somewhat (ATs
obtained from the stolen RT wouldn't be usable) it's hard to say
if the cost is worth the benefit.



On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck
mailto:phili...@pragmaticwebsecurity.com>> wrote:

Yeah, browser-based apps are pure fun, aren’t they? :)

The reason I covered a couple of (pessimistic) XSS scenarios
is that the discussion started with an assumption that the
attacker already successfully exploited an XSS vulnerability.
I pointed out how, at that point, finetuning DPoP proof
contents will have little to no effect to stop an attack. I
believe it is important to make this very clear, to avoid
people turning to DPoP as a security mechanism for
browser-based applications.


Specifically to your question on including the hash in the
proof, I think these considerations are important:

1. Does the inclusion of the AT hash stop a concrete attack
scenario?
2. Is the “cost” (implementation, getting it right, …) worth
the benefits?


Here’s my view on these considerations (*/specifically for
browser-based apps, not for other types of applications/*):

1. The proof precomputation attack is already quite complex,
and short access token lifetimes already reduce the window of
attack. If the attacker can steal a future AT, they could
also precompute new proofs then.
2. For browser-based apps, it seems that doing this
complicates the implementation, without adding much benefit.
Of course, libraries could handle this, which significantly
reduces the cost.


Note that these comments are specifically to complicating the
spec and implementation. DPoP’s capabilities of using
sender-constrained access tokens are still useful to counter
various other scenarios (e.g., middleboxes or APIs abusing
access tokens). If other applications would significantly
benefit from having the hash in the proof, I’m all for it.

On a final note, I would be happy to help clear up the
details on web-based threats and defenses if necessary.

—
*Pragmatic Web Security*
/Security for developers/
https://pra

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Jim Manico]

fic is mixed in with the user’s own
requests, making them harder to distinguish or to block

Overall, DPoP can only protect against XSS to the same level
as HttpOnly cookies. This is not nothing, but it means it
only prevents relatively naive attacks. Given the
association of public key signatures with strong
authentication, people may have overinflated expectations if
DPoP is pitched as an XSS defence.


Yes, in the cookie world this is known as “Session Riding”.
Having the worker for token isolation would make it possible
to enforce a coarse-grained policy on outgoing requests to
prevent total abuse of the AT.

My main concern here is the effort of doing DPoP in a browser
versus the limited gains. It may also give a false sense of
security.



With all this said, I believe that the AS can lock down its
configuration to reduce these attack vectors. A few initial
ideas:

1. Disable silent flows for SPAs using RT rotation
2. Use the sec-fetch headers to detect and reject non-silent
iframe-based flows

For example,  an OAuth 2.0 flow in an iframe in Brave/Chrome
carries these headers:
/
sec-fetch-dest: iframe
sec-fetch-mode: navigate
sec-fetch-site: cross-site
sec-fetch-user: ?1
/


Philippe


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



/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


--
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

[Jim Manico]

Thanks for this message, Vittorio.

> Say that I allow LinkedIn to tweet on my behalf. Once I have done 
that, it doesn’t matter whether I stay logged in their web app or otherwise.


Ah, of course. That makes perfect sense.

I should had been a lot more specific. I was commenting more on how many 
mobile apps which use OAuth AuthZ refresh/access tokens from the native 
client RFC do not support logout. I noticed that when I log out of the 
Facebook mobile app, my refresh token is still active and I'm not really 
fully logged out. If I am in a native client triggering a logout event, 
I would expect to see revocation in play!


Also, in an microservice environment where JWT's are used as client side 
sessions, logout events often do not actually revoke currently active 
JWT's. #lazyLogoutBooo


That's all from me. =)

Aloha, Jim

On 10/6/20 11:21 AM, vittorio.berto...@auth0.com wrote:

Hey Jim, regarding

Every logout event should trigger token revocation

That isn’t necessarily the case. An access token represents the ability of a 
client to access a given resource; the fact that it requires an authentication 
transaction/session establishment to be issued to the client does not mean that 
the AT lifetime is tied to the lifetime of that session. Say that I allow 
LinkedIn to tweet on my behalf. Once I have done that, it doesn’t matter 
whether I stay logged in their web app or otherwise. Even if I log out of the 
session in which context I got my twitter AT, I can still post on LinkedIn from 
my native LinkedIn app and the corresponding post will show up on twitter as 
well.
Now, one might choose to *explicitly* tie tokens lifetime to originating 
sessions lifetime, see the discussion on the OpenID Connect group about a 
possible online_access scope for influencing RTs and Ats (in particular, in the 
context of SPAs) but that's additional semantic that isn’t defined today.

-Original Message-
From: OAuth  On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint


In this model, considering that token revocations don't happen a lot...

Just a brief note, a secure piece of software makes the logout feature 
prominent. Every logout event should trigger token revocation.

I’m mentioning this because a lot of OAuth solutions in the mobile space 
literally ignore the logout event, such as Facebook’s mobile OAuth solution.

- Jim


On Oct 4, 2020, at 6:55 AM, Nicolas Mora  wrote:

Hello,


Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :

There might be some kind of pushed events between the AS and the RS when
a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all.
Like this, the RS knows if a JWT AT has been revoked or not.


If there are some kind of pushed events between the AS and the RS,
then it could push the revoked (and/or expired) opaque AT too, giving
almost no advantage to JWT ATs.


Not necessarily, let's say the AS informs the RS only of the revoked
ATs, when a RS checks an AT, it verifies the signature first, then the
claims, then checks if the AT has been revoked by checking its
internal list filled by the AS pushed events.

In this model, considering that token revocations don't happen a lot,
the ratio revoked AT/valid AT is very low, so the advantage of a JWT
is important, because it means not so much communication between the
AS and the RSs, and a very reliable AT.

But this means a communication mechanism that isn't standardized yet.

/Nicolas

___
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


--
Jim Manico
Manicode Security
https://www.manicode.com


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

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

[Jim Manico]

> In this model, considering that token revocations don't happen a lot...

Just a brief note, a secure piece of software makes the logout feature 
prominent. Every logout event should trigger token revocation.

I’m mentioning this because a lot of OAuth solutions in the mobile space 
literally ignore the logout event, such as Facebook’s mobile OAuth solution. 

- Jim

> On Oct 4, 2020, at 6:55 AM, Nicolas Mora  wrote:
> 
> Hello,
> 
>> Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :
>> 
>>There might be some kind of pushed events between the AS and the RS when
>>a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all.
>>Like this, the RS knows if a JWT AT has been revoked or not.
>> 
>> 
>> If there are some kind of pushed events between the AS and the RS, then
>> it could push the revoked (and/or expired) opaque AT too, giving almost
>> no advantage to JWT ATs.
>> 
> Not necessarily, let's say the AS informs the RS only of the revoked
> ATs, when a RS checks an AT, it verifies the signature first, then the
> claims, then checks if the AT has been revoked by checking its internal
> list filled by the AS pushed events.
> 
> In this model, considering that token revocations don't happen a lot,
> the ratio revoked AT/valid AT is very low, so the advantage of a JWT is
> important, because it means not so much communication between the AS and
> the RSs, and a very reliable AT.
> 
> But this means a communication mechanism that isn't standardized yet.
> 
> /Nicolas
> 
> ___
> 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] third party applications

[Jim Manico]

It does not make sense to use OAuth in most single party situations. These 
single-party OAuth use cases are frequently a complete misuse of the framework. 
I +1 the language “3rd party” in an effort to steer implementors in the right 
direction.

--
Jim Manico
@Manicode


> On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt 
>  wrote:
> 
> 
>> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
>> 
>> Well, OAuth is not very useful in a monolithic application. No need for an 
>> interoperable protocol for that kind of application.
> 
> I don’t know why we need to make any assumptions about the application that 
> uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
> assumptions they must be relevant for the protocol design. 
> 
> So again, why is “independent” or “third-party” relevant for the protocol 
> design? 
> 
>> 
>> And in separating functions, you are creating separate trust domains. Yes, 
>> it is still all internal, but it enables a separation of concerns.
>> ᐧ
>> 
>> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt 
>>  wrote:
>> In my experience OAuth is used in 1st party scenarios as means to separate 
>> functions (e.g. central user management vs. different products) within the 
>> same trust domain thus enabling architectural flexibility. 
>> 
>> I would just remove any constraint on the kind of applications OAuth can be 
>> used for. I don’t see how this governs the protocol design.  
>> 
>>>> On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
>>> 
>>> The driver in my opinion for first-party use of OAuth is to separate the 
>>> trust domains so that the application is scoped in what it can do vs an 
>>> application that has full access to all resources. I agree that third-party 
>>> can indicate that internal use does not apply. How about the following?
>>> 
>>>   The OAuth 2.1 authorization framework enables an independent
>>>   application to obtain limited access to an HTTP service, either on
>>>   behalf of a resource owner by orchestrating an approval interaction
>>>   between the resource owner and the HTTP service, or by allowing the
>>>   application to obtain access on its own behalf.  This
>>>   specification replaces and obsoletes the OAuth 2.0 Authorization
>>>   Framework described in RFC 6749.
>>> ᐧ
>>> 
>>>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
>>>>  wrote:
>>> I agree. OAuth works for 3rd as well as 1st parties as well. 
>>> 
>>>> On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Can "third-party" term be removed from the specification?
>>>> 
>>>> The standard and associated best practices apply to other applications 
>>>> that act on behalf of a resource owner, too (internal, "first-party" and 
>>>> etc).
>>>> 
>>>> Regards,
>>>> 
>>>> Dima
>>>> 
>>>> The OAuth 2.1 authorization framework enables a third-party
>>>> 
>>>>   application to obtain limited access to an HTTP service, either on
>>>>   behalf of a resource owner by orchestrating an approval interaction
>>>>   between the resource owner and the HTTP service, or by allowing the
>>>>   third-party application to obtain access on its own behalf.  This
>>>>   specification replaces and obsoletes the OAuth 2.0 Authorization
>>>>   Framework described in 
>>>> RFC 6749.
>>>> ___
>>>> 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] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Jim Manico]

I politely encourage the rules to be bent and to integrate this basic but 
fundamental security control into the core standard.

This is just basic security; we want as much basic security in the core of any 
standard. Dev’s now need to read 20 standards to get OAuth2 basics... and 
that’s a barrier to entry.

--
Jim Manico
@Manicode

> On Jul 30, 2020, at 3:21 PM, Dick Hardt  wrote:
> 
> 
> One of the constraints of the OAuth 2.1 document that aligned the WG was it 
> would have no new features.
> 
> I'd recommend a separate document for the cookie bearer token feature. 
> 
> ᐧ
> 
>> On Thu, Jul 30, 2020 at 12:15 PM Jim Manico  wrote:
>> Yea to cookie configuration suggestions!
>> 
>> I suggest SameSite=LAX at least, which is actually the default behavior in 
>> chrome if you do not set the samesite value. LAX will not break links that 
>> originate from emails, STRICT will.
>> 
>> Point being is that CSRF defense is easy. XSS defense is brutally hard in 
>> apps with complex UI’s!
>> 
>> --
>> Jim Manico
>> @Manicode
>> 
>> 
>>>> On Jul 30, 2020, at 1:13 PM, Warren Parad  wrote:
>>>> 
>>> 
>>>> Cookie storage of tokens does leave one open to CSRF attacks so it's 
>>>> certainly a trade-off. But CSRF is much easier to defense against that XSS 
>>>> and cookies are a better choice if the specific risk of having tokens 
>>>> stolen via XSS matters to your threat model.
>>> 
>>> I would assume if we included cookie language, it would explicitly specify 
>>> Secure; HttpOnly; SameSite=Strict as the recommendation, and then neither 
>>> XSS nor CSRF should be a problem (right?)
>>> 
>>> 
>>>> OAuth 2.1 isn't supposed to add new features that don't already exist, but 
>>>> this sounds like a good candidate to develop as an OAuth extension.
>>> 
>>> Is this really a new feature though?
>>> 
>>> Okay, I'll submit that RFC 6749 does state the cookie wouldn't be created 
>>> by the AS.
>>>> 5.1.  Successful Response
>>>>The authorization server issues an access token and optional refresh
>>>>token, and constructs the response by adding the following parameters
>>>>to the entity-body of the HTTP response with a 200 (OK) status code:
>>>  
>>> However that wouldn't prevent a client using the password grant (I know I 
>>> said a bad word) or authorization code flow from creating the cookie to 
>>> contain that. Specifically
>>>> 7.  Accessing Protected Resources
>>>>The client accesses protected resources by presenting the access
>>>>token to the resource server.  The resource server MUST validate the
>>>>access token and ensure that it has not expired and that its scope
>>>>covers the requested resource.  The methods used by the resource
>>>>server to validate the access token (as well as any error responses)
>>>>are beyond the scope of this specification but generally involve an
>>>>interaction or coordination between the resource server and the
>>>>authorization server.
>>>>The method in which the client utilizes the access token to
>>>>authenticate with the resource server depends on the type of access
>>>>token issued by the authorization server.  Typically, it involves
>>>>using the HTTP "Authorization" request header field [RFC2617] with an
>>>>authentication scheme defined by the specification of the access
>>>>token type used, such as [RFC6750].
>>> 
>>> So that's definitely some gray area. Although perhaps I'm missing a 
>>> relevant section. If we are going to go so far to detail a list of possible 
>>> RS bearer token possible locations (i.e. Header and Body), to what I assume 
>>> is to implicitly say Don't use a query parameter. It also suggests Don't 
>>> use a cookie at all, even with SameSite=Strict. Although maybe that is the 
>>> point.
>>> 
>>> For my reference, what makes a new feature and what makes an OAuth 
>>> extension?
>>> 
>>> 
>>> Warren Parad
>>> Founder, CTO
>>> Secure your user data and complete your authorization architecture. 
>>> Implement Authress.
>>> 
>>> 
>>>> On Thu, Jul 30, 2020 at 6:46 PM Aaron Parecki  wrote:
>>>> I haven't seen any OAuth drafts that talk about sending OAuth access 
>>>> tokens in HTTP cookies. OAuth

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Jim Manico]

Yea to cookie configuration suggestions!

I suggest SameSite=LAX at least, which is actually the default behavior in 
chrome if you do not set the samesite value. LAX will not break links that 
originate from emails, STRICT will.

Point being is that CSRF defense is easy. XSS defense is brutally hard in apps 
with complex UI’s!

--
Jim Manico
@Manicode


> On Jul 30, 2020, at 1:13 PM, Warren Parad  wrote:
> 
> 
>> Cookie storage of tokens does leave one open to CSRF attacks so it's 
>> certainly a trade-off. But CSRF is much easier to defense against that XSS 
>> and cookies are a better choice if the specific risk of having tokens stolen 
>> via XSS matters to your threat model.
> 
> I would assume if we included cookie language, it would explicitly specify 
> Secure; HttpOnly; SameSite=Strict as the recommendation, and then neither XSS 
> nor CSRF should be a problem (right?)
> 
> 
>> OAuth 2.1 isn't supposed to add new features that don't already exist, but 
>> this sounds like a good candidate to develop as an OAuth extension.
> 
> Is this really a new feature though?
> 
> Okay, I'll submit that RFC 6749 does state the cookie wouldn't be created by 
> the AS.
>> 5.1.  Successful Response
>>The authorization server issues an access token and optional refresh
>>token, and constructs the response by adding the following parameters
>>to the entity-body of the HTTP response with a 200 (OK) status code:
>  
> However that wouldn't prevent a client using the password grant (I know I 
> said a bad word) or authorization code flow from creating the cookie to 
> contain that. Specifically
>> 7.  Accessing Protected Resources
>>The client accesses protected resources by presenting the access
>>token to the resource server.  The resource server MUST validate the
>>access token and ensure that it has not expired and that its scope
>>covers the requested resource.  The methods used by the resource
>>server to validate the access token (as well as any error responses)
>>are beyond the scope of this specification but generally involve an
>>interaction or coordination between the resource server and the
>>authorization server.
>>The method in which the client utilizes the access token to
>>authenticate with the resource server depends on the type of access
>>token issued by the authorization server.  Typically, it involves
>>using the HTTP "Authorization" request header field [RFC2617] with an
>>authentication scheme defined by the specification of the access
>>token type used, such as [RFC6750].
> 
> So that's definitely some gray area. Although perhaps I'm missing a relevant 
> section. If we are going to go so far to detail a list of possible RS bearer 
> token possible locations (i.e. Header and Body), to what I assume is to 
> implicitly say Don't use a query parameter. It also suggests Don't use a 
> cookie at all, even with SameSite=Strict. Although maybe that is the point.
> 
> For my reference, what makes a new feature and what makes an OAuth extension?
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement 
> Authress.
> 
> 
>> On Thu, Jul 30, 2020 at 6:46 PM Aaron Parecki  wrote:
>> I haven't seen any OAuth drafts that talk about sending OAuth access tokens 
>> in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't 
>> already exist, but this sounds like a good candidate to develop as an OAuth 
>> extension.
>> 
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>> https://oauth2simplified.com 
>> 
>>> On Thu, Jul 30, 2020 at 9:35 AM Jim Manico  wrote:
>>> In a browser, HTTPOnly cookies are the only location where an access (or 
>>> other) token can be stored in a way where it cannot be stolen from XSS.
>>> 
>>> It's a very strong place to store tokens from a security point of view.
>>> 
>>> Cookie storage of tokens does leave one open to CSRF attacks so it's 
>>> certainly a trade-off. But CSRF is much easier to defense against that XSS 
>>> and cookies are a better choice if the specific risk of having tokens 
>>> stolen via XSS matters to your threat model.
>>> 
>>> - Jim
>>> 
>>> On 7/30/20 11:43 AM, Warren Parad wrote:
>>>> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens
>>>> 
>>>> It seems recently more and more common to pass the access_token to some RS 
>>>> via a cookie, yet 7.2.1 says it defines two methods. I think we need

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Jim Manico]

In a browser, HTTPOnly cookies are the *only* location where an access 
(or other) token can be stored in a way where it *cannot be stolen from 
XSS*.


It's a very strong place to store tokens from a security point of view.

Cookie storage of tokens does leave one open to CSRF attacks so it's 
certainly a trade-off. But CSRF is much easier to defense against that 
XSS and cookies are a better choice if the specific risk of having 
tokens stolen via XSS matters to your threat model.


- Jim

On 7/30/20 11:43 AM, Warren Parad wrote:

https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens

It seems recently more and more common to pass the access_token to 
some RS via a cookie, yet 7.2.1 says it defines two methods. I think 
we need some RFC2119 
<https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119> keywords 
here, to suggest that either SHOULD use one of these two, or MUST. And 
then optionally state whether or not we recommend or reject the use of 
cookies as a place for access tokens. It's also possible that the 
language threw me off, because would an access token in a cookie be a 
bearer token, but no matter, if I'm having this thought, then surely 
others have it as well, right?


image.png



Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. 
Implement Authress <https://bit.ly/37SSO1p>.


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


--
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

[Jim Manico]

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 
> forbidding the user of ROPC.

Absolutely and this seems like a good thing. ROPC seems very close to a use 
case that calls for OIDC instead of a OAuth2x token so I endorse the move.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 12, 2020, at 1:23 PM, Francis Pouatcha  wrote:
> 
> 
> 
> 
>> On Tue, May 12, 2020 at 9:50 AM Jim Manico  wrote:
>> Forgive me if this question is late or poor context, but wouldn’t OIDC be a 
>> better replacement for ROPC since it’s essentially a authentication flow?
>> 
>> What use case for ROPC mandates OAuth2 over OIDC?
> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 
> forbidding the user of ROPC.
> 
>> 
>> --
>> Jim Manico
>> @Manicode
>> 
>>>> On May 11, 2020, at 11:00 PM, Francis Pouatcha 
>>>>  wrote:
>>>> 
>>> 
>>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password 
>>> Credentials) with the following reasoning:
>>> 
>>> Auth Code Grant:
>>> There are  many use cases on the market where redirection based flows do 
>>> not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the 
>>> complexity of user agents on non controllable client devices still make 
>>> user agent redirection a challenge. 
>>> 
>>> Client Credentials Grant:
>>> Requires the registration of an oAuth client.
>>> - Citing the iot device use cases Beena which do not have a comfortable way 
>>> to have iot devices register with AS.
>>> - This is a registration flow for the oAuth client role  and for the RO 
>>> (Resource Owner). Remember resource owner credentials might be sourced from 
>>> system external to the AS  like company's LDAP. oAuth Client Credentials 
>>> are generally managed by the AS.
>>> For these reasons, we shall not use Client Credential Grant to manage RO 
>>> authorization.
>>> 
>>> ROPC:
>>> Having an oAuth Client proxy the auth request of the RO to the AS only 
>>> presents a security risk if the oAuth Client is a third party application. 
>>> Therefore, the decision on whether to accept ROPC for a specified client 
>>> shall be left to the AS. Discarding this use case will take a lot of 
>>> business from oAuth servers back to the old market.
>>> 
>>> Beside this, I mentioned in my previous post that there are use cases in 
>>> the market where permanent passwords are replaced with one time passwords.
>>> 
>>> A lot of work is also being done in the direction of having the RO send 
>>> signed proof of ownership to the AS through the ROPC  flow using the 
>>> password field.
>>> 
>>> Therefore, I am ok with raising the attention of  implementers the same way 
>>> we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / 
>>> oAuth Client can guarantee security of the RO credentials exposed to the 
>>> oAuth Client. 
>>> 
>>> /Francis
>>> -- 
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead at adorys
>>> https://adorsys-platform.de/solutions/
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

[Jim Manico]

Forgive me if this question is late or poor context, but wouldn’t OIDC be a 
better replacement for ROPC since it’s essentially a authentication flow?

What use case for ROPC mandates OAuth2 over OIDC?

--
Jim Manico
@Manicode

> On May 11, 2020, at 11:00 PM, Francis Pouatcha 
>  wrote:
> 
> 
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password 
> Credentials) with the following reasoning:
> 
> Auth Code Grant:
> There are  many use cases on the market where redirection based flows do not 
> work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complexity of 
> user agents on non controllable client devices still make user agent 
> redirection a challenge. 
> 
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable way 
> to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO 
> (Resource Owner). Remember resource owner credentials might be sourced from 
> system external to the AS  like company's LDAP. oAuth Client Credentials are 
> generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO 
> authorization.
> 
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only 
> presents a security risk if the oAuth Client is a third party application. 
> Therefore, the decision on whether to accept ROPC for a specified client 
> shall be left to the AS. Discarding this use case will take a lot of business 
> from oAuth servers back to the old market.
> 
> Beside this, I mentioned in my previous post that there are use cases in the 
> market where permanent passwords are replaced with one time passwords.
> 
> A lot of work is also being done in the direction of having the RO send 
> signed proof of ownership to the AS through the ROPC  flow using the password 
> field.
> 
> Therefore, I am ok with raising the attention of  implementers the same way 
> we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / 
> oAuth Client can guarantee security of the RO credentials exposed to the 
> oAuth Client. 
> 
> /Francis
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> ___
> 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

[Jim Manico]

It’s actually worse. Parameters in a URL leak over bookmarks, browser history, 
logs everywhere, referrer headers... 

One of the most primary rules of secure coding on the web is to never put 
sensitive data in a URL for •any• verb, not just GET.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle 
>  wrote:
> 
> 
> +1 to Justin’s comments. From a security standpoint parameters in the query  
> string are no different from those in JWT unprotected headers (or protected 
> if they’re also in the request object). Although I‘d amend Justin’s 
> suggestion to say that if a parameter is both inside the request object and 
> outside and they do not match, reject the request as suspicious.
> 
>>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>>> 
>>  I don’t agree with this stance from a security or implementation 
>> perspective. 
>> 
>> If there’s a clear order of precedence for the information, it’s not 
>> particularly problematic. Everything inside the request object is to be 
>> taken over things outside the request object. We have the exact same 
>> semantics and process with dynamic registration, where the software 
>> statement is carried alongside plain JSON claims, and the two are mixed with 
>> a very simple algorithm:
>> 
>>  - If a field is inside the signed payload, use that value and ignore any 
>> copy of it on the outside
>>  - If a field is not inside the signed payload and is outside the signed 
>> payload, use the outside value
>> 
>> Can someone please point out a concrete security issue with this algorithm? 
>> This is the extent of the “merge” semantics that we need here, and it would 
>> solve not only the ability to use this for use cases that call for a more 
>> static request object (perhaps signed by a third party and not the client) 
>> along side the plain parameters that can vary, but also the backwards 
>> compatibility issue that’s been discussed. With this algorithm in place, you 
>> could have OIDC clients actually be compliant with the spec, since OIDC 
>> requires replication of the values inside the request object on the outside 
>> with exact matches. An OIDC server wouldn’t be fully compliant with the new 
>> spec since it would reject some compliant JAR requests that are missing the 
>> external parameters, but that’s fairly easy logic to add on the OIDC side. 
>> And in that case you get a matrix of compatibility like:
>> 
>> 
>>   JAR Server | OIDC Server  |
>> ++--+
>> JAR Client  | YES|  NO  |
>> OIDC Client | YES| YES  |
>> 
>> Breaking one out of the four possible combinations in a very predictable way 
>> is, I think, the best way to handle backwards compatibility here. 
>> 
>> But between this issue and JAR’s problematic call for the value of a 
>> request_uri to always be a JWT and be fetchable by the AS (neither of which 
>> are true in the case of PAR) makes me think we need to pull this back and 
>> rework those things, in a push back to the IESG’s comments.
>> 
>>  — Justin
>> 
>> 
>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan  wrote:
>>> 
>>> I agree with this, particularly the security concerns of merging. If we 
>>> merge, we can much guarantee there will eventually be a security issue 
>>> where an attacker is able to gain an advantage by adding a parameter to the 
>>> url query (which the server would then happily process if that parameter 
>>> isn’t found inside the request object). Ruling out that case makes security 
>>> analysis (particularly when creating new OAuth2 parameters) significantly 
>>> simpler.
>>> 
>>> Putting the iss in the JWE header and having the client_id duplicated 
>>> outside the request object seem to address all the concerns I’ve seen 
>>> raised.
>>> 
>>> (It seems like it may be unnecessary to have the client_id duplicated 
>>> outside if the request_uri is a PAR one though.)
>>> 
>>> Joseph
>>> 
>>> 
>>> 
>>>> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>>>> 
>>>> I agree with the IESG reasoning that merging is problimatic.  Once we
>>>> allow that given a unknown list of possible paramaters with diffrent
>>>> security properties it would be quite difficult to specify safely.
>>>> 
>>>> Query paramaters can still be sent outside the JAR, but if they are in
>

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Jim Manico]

> I would argue TLS basically prevents leakage and not replay

Doesn’t token binding, which is esentially a TLS extension, prevent some forms 
of token replay?

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 22, 2019, at 7:26 AM, Richard Backman, Annabelle 
>  wrote:
> 
> 
> > Yes of course. But this is the HMAC *tag* not the original key.
> Sure. And if the client attenuates the macaroon, it is used as a key that the 
> client proves possession of by presenting the chained HMAC. Clients doing 
> DPoP aren’t proving possession of the “original key” (i.e., a key used to 
> generate the access token) either.
>  
> > Well, you don’t have to return a key from the token endpoint for a start.
> Yes, that’s what I meant by saying that it eliminates key negotiation. Though 
> I suppose it’s more correct to say that it inlines it. The AS still provides 
> a key, it just happens to be part of the access token.
>  
> Macaroons are an interesting pattern, but not because they’re not doing PoP. 
> Proof of possession is pretty core to the whole idea of digital signatures 
> and HMACs. What makes them interesting is the way they inline key 
> distribution. Whether or not they’re applicable to DPoP depends, ultimately, 
> on the use cases DPoP is targeting and the threats it is trying to mitigate.
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: Neil Madden 
> Date: Friday, November 22, 2019 at 3:09 PM
> To: "Richard Backman, Annabelle" 
> Cc: Brian Campbell , oauth 
> Subject: Re: [OAUTH-WG] New Version Notification for 
> draft-fett-oauth-dpop-03.txt
>  
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle  
> wrote:
>  
> Macaroons are built on proof of possession. In order to add a caveat to a 
> macaroon, the sender has to have the HMAC of the macaroon without their 
> caveat.
>  
> Yes of course. But this is the HMAC *tag* not the original key. They can’t 
> change anything the AS originally signed. 
> 
> 
> The distinctive property of macaroons as I see it is that they eliminate the 
> need for key negotiation with the bearer. How much value this has over the AS 
> just returning a symmetric key alongside the access token in the token 
> request, I’m not sure.
>  
> Well, you don’t have to return a key from the token endpoint for a start. The 
> client doesn’t need to create and send any additional token. The whole thing 
> works with existing standards and technologies and can be incrementally 
> adopted as required. If RSes do token introspection already then they need 
> zero changes to support this.
> 
> 
> There are key distribution challenges with that if you are doing validation 
> at the RS, but validation at the RS using either approach means you’ve lost 
> protection against replay by the RS. This brings us back to a core question: 
> what threats are in scope for DPoP, and in what contexts?
>  
> Agreed, but validation at the RS is premature optimisation in many cases. And 
> if you do need protection against that the client can even append a 
> confirmation key as a caveat and retrospectively upgrade a bearer token to a 
> pop token. They can even do transfer of ownership by creating copies of the 
> original token bound to other certificates/public keys. 
>  
> Neil
>  
> 
> 
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: OAuth  on behalf of Neil Madden 
> 
> Date: Friday, November 22, 2019 at 4:40 AM
> To: Brian Campbell 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] New Version Notification for 
> draft-fett-oauth-dpop-03.txt
>  
> At the end of my previous email I mentioned that you can achieve some of the 
> same aims as DPoP without needing a PoP mechanism at all. This email is that 
> follow-up.
>  
> OAuth is agnostic about the format of access tokens and many vendors support 
> either random string database tokens or JWTs. But there are other choices for 
> access token format, some of which have more interesting properties. In 
> particular, Google proposed Macaroons a few years ago as a "better cookie" 
> [1] and I think they systematically address many of these issues when used as 
> an access token format.
>  
> For those who aren't familiar with them, Macaroons are a bit like a HS256 
> JWT. They have a location (a bit like the audience in a JWT) and an 
> identifier (an arbitrary string) and then are signed with HMAC-SHA256 using a 
> secret key. (There's no claims set or headers - they are very minimal). In 
> this case the secret key would be owned by the AS and used to sign 
> macaroon-based access tokens. Validating the token would be done via token 
> introspection at the AS.
&

Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

[Jim Manico]

I love you Neil.

--
Jim Manico
@Manicode

> On Oct 30, 2019, at 3:18 PM, Neil Madden  wrote:
> 
> 
> If you can point out where I recommended disabling TLS or not bothering to 
> strip headers from incoming requests, or anything else along those lines then 
> please let me know. Otherwise, yes we’re done here. 
> 
>>> On 30 Oct 2019, at 17:19, Salz, Rich  wrote:
>>> 
>> 
>> To quote your previous claim: "There is no such thing as an unguessable 
>> name."
>> Right.  That doesn’t mean *I* have to guess it.
>> 
>> Even if your deployment team had such staggeringly bad operational security 
>> practices as to allow people to take packet captures from an internal 
>> network and show them on public slides without any kind of questions being 
>> asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION 
>> WHERE YOU USED A WELL-KNOWN HEADER NAME*!
>> Yes you are worse off.  Because that now-exposed header value can be used 
>> for spoofing.  As opposed to protection by TLS, and then sending the 
>> plaintext message around.
>>  
>> I don't know how many different ways I can say that this is a defense in 
>> depth
>> Because it is not.  It is taking an application-level piece of configuration 
>> data and requiring it to be treated as if it were crypto material. Which it 
>> cannot be, because multiple parties need to know it (as I said, the proxy, 
>> the backend, the app developers, the support team, etc).  It’s defense by 
>> “collapsing layers” rather than “in depth.”
>>  
>> As with all defense in depth, the aim is to be more than 1 configuration 
>> mistake away from total compromise.
>> But that is exactly what you are proposing. Exposing the header *is* a total 
>> compromise and multiple entities will need to know that header value.
>>  
>> At any rate,  I think we’re done here.
>>  
> ___
> 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] On XSS

[Jim Manico]

OAuth community,

XSS is a problematic risk in all web applications. It’s easy to introduce into 
apps, hard to find, and one variant is dramatically growing - DOM XSS.

If you care about this risk; please give this a read from one of the worlds 
best on this topic and a potential solution (at least for DOM XSS) that will 
arrive in the near future.

https://developers.google.com/web/updates/2019/02/trusted-types

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

>  Is this a matter of saying they should have an API for these clients
which exposes less of the risky activities? That cookies provide a
defense against XSS exfiltration? And/or other?

HTTPOnly cookies prevent exfiltration of session or token data stored in
cookies. Those cookies can be REPLAYED via XSS (stored request forgery
via XSS) but they indeed cannot be stolen.

I also reject serverless SPA architectures that store tokens from a wide
variety of services, especially for high risk apps that use complex web
UI's. The chance of building such things securely for most teams is
painfully low.

- Jim


On 12/7/18 5:27 PM, David Waite wrote:
>> On Dec 7, 2018, at 5:50 AM, Jim Manico  wrote:
> 
>> I still encourage developers who are not XSS guru’s to stick to cookie based 
>> sessions or stateless artifacts to talk to the back end and keep OAuth 
>> tokens only flying intra-server. It’s an unpopular opinion, but even 
>> moderately good XSS defense is equally unpopular
> Is this a matter of saying they should have an API for these clients which 
> exposes less of the risky activities? That cookies provide a defense against 
> XSS exfiltration? And/or other?
>
> -DW
>
>
-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

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

[Jim Manico]

I wanted to address Vittorio’s comment on XSS and LocalStorage.

One XSS attack can extract all of LocalStorage in one line of code. It’s 
trivial. And after studying XSS for years, I believe that most developers are 
not capable of building good XSS defense into complex UI’s and the trends to 
use Angular and React are not helping the situation; they just move the problem 
around.

Sure, few dev teams who have VERY specialized and rare developer resources can 
build XSS resistant apps, if they know how to properly escape, sanitize, 
validate, use safe JS, embed JSON properly, use sandboxing properly, and build 
unique CSP policies per page. And for most, good luck with that.

This is why I still hold onto the belief that OAuth solutions that store tokens 
in the browser for high risk apps is a bad idea. 

I still encourage developers who are not XSS guru’s to stick to cookie based 
sessions or stateless artifacts to talk to the back end and keep OAuth tokens 
only flying intra-server. It’s an unpopular opinion, but even moderately good 
XSS defense is equally unpopular.

At OWASP there are •several• guides you need to master to understand XSS 
defense. And this does not even scratch the surface of what is needed to master 
XSS defense in React/Angular, not to mention the complexity of CSP which 
requires per-page policies.

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Unpopularity yours,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Dec 6, 2018, at 1:09 PM, Vittorio Bertocci 
>  wrote:
> 
> Thank you Torsten.
> I think that a lot of the considerations below need to be tempered with 
> concrete considerations about the features developers can actually rely on 
> today.
> I agree with identifying the theoretical framework and north star we want to 
> aspire to, but if we are framing the recommendation here in form of practice, 
> we have to ensure it is actionable for developers. I am not pushing back on 
> ideas, but I just want to make sure that when customers hear this advice, 
> they are actually in the position to apply it. And if there are missing 
> pieces, perhaps we should consider this more as guidance to the vendors that 
> need to provide key enablers for this to become viable, and recommend it as 
> practice to customers only when that happened.
> I add more details inline below, however I have a meta point to make: did all 
> the vendors on the list work on proof of concepts to ensure that the 
> practices recommended here can work with your product, end to end? 
> I don't mean just doing a code+PKCE demo in JS, I mean complying with things 
> like RT rotation and revocation end to end, using released features that your 
> customers can use today. If you did, it might really help to use them to make 
> those discussions more concrete. If you didn't, then calling the proposal a 
> practice might be premature.
> inline:
>  
> 
> > Regarding protection at rest: what’s the attacker model in those 
> > discussions? XSS? Local attacks on the device?
> The main concern is XSS. You can just google token session storage to find an 
> onslaught of articles and forum threads on the topic. To pick one at random, 
> here's the one from Mozilla.
> We can argue on what's worse between XSS and URL leaks, but I don't think we 
> can ignore the pervasive ongoing debate and perception that use of local 
> storage for sensitive data is bad.
> 
> 
> >  Much of the mechanisms are platform specific and need platform expertise. 
> I don't follow this one. We are targeting the browser, right? What are the 
> platform specific features you are thinking about?
> 
> 
> > From the OAuth protocol perspective, impact of RT leakage can be limited 
> > through rotation. So I would argue RTs are better protected than ATs.
> AFAIK relatively few providers today offer RT rotation (Microsoft is an 
> example of widely adopted provider who doesn't), and even if they do: if you 
> steal an RT and use it to get an AT you will enjoy full AT use until the 
> legitimate client attempts a refresh, which will be typically at near expiry 
> time, hence gaining very little. And given that even fewer providers offer 
> access token revocation as a consequence of attempted RT reuse, even more 
> frequent refresh attempts won't reduce the time the attacker has to use the 
> access token they obtained. Hence I am not sure I buy the argument that RTs 
> are better protected than ATs, both from the theoretical perspective and the 
> practical one. And in practical terms, if a developer is tied to a provider 
> that doesn't offer full RT rotation asking them to store RTs will make them 
> worse off than they are today. I am of co

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

[Jim Manico]

Nat,

How is proof of possession established in a modern web browser in the
implicit flow?

My understanding is that token binding was removed from Chrome recently
effectively killing browser-based PoP tokens.

https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

Am I missing something?

Aloha, Jim


On 11/27/18 9:00 PM, Nat Sakimura wrote:
> I am actually -1. 
>
> +1 for public client and the tokens that are not sender/key constrained. 
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming. 
> Implicit (well, Hybrid “token id_token” really) is very useful in
> certain cases. 
> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the
> one explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it
> is very useful. 
> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider. 
>
> So, the text is generally good but it needs to be constrained like
> “Unless the client is confidential and the access token issued is key
> constrained, ... “
>
> Best, 
>
> Nat Sakimura
>
>
> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov  <mailto:vladi...@connect2id.com>>:
>
> +1 to recommend the deprecation of implicit.
>
> I don't see a compelling reason to keep implicit when there is an
> established alternative that is more secure.
>
> Our duty as WG is to give developers the best and most sensible
> practice.
>
> CORS adoption is currently at 94% according to
> https://caniuse.com/#feat=cors
>
> Vladimir
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

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

[Jim Manico]

Manicode Security is strongly in favor of deprecating the implicit flow in 
favor of the authorization code flow as suggested by this recommendation.

We're also eager to see secure implementations for SPA delegation be clarified 
by the working group as well.

Thank you for this important work!

Aloha and Well Wishes,
-- 
Jim Manico
Manicode Security
https://www.manicode.com

On 11/19/18 4:04 PM, Hannes Tschofenig wrote:

> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM
> are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint,
> Torsten suggested to use the authorization code instead of the
> implicit grant in call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
>
> Hannes & Rifaat
>
>  
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

[Jim Manico]

I want to +1 this as well. This really got my attention as an impressive and 
straightforward defense technique.

Jim


> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt  wrote:
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of 
> requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov 
>>  wrote:
>>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with 
>>> automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and 
>>> invalidate the old one. This restricts the lifetime of a refresh token. If 
>>> someone (might be the legit client or an attacker) submits one of the 
>>> older, invalidated refresh token, the AS might interpret this as a signal 
>>> indicating token leakage and revoke the valid refresh token as well. We 
>>> used this technique at Deutsche Telekom since our first OAuth 2.0 
>>> implementation back in 2012.
>> This is a clever solution. Did you experience any false positives, e.g. due 
>> to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the 
>> end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Jim Manico]

What you call pessimism I call stating fact!  

This has nothing to do with SPA apps. Like Neil says any XSS in play and token 
binding, HTTPOnly and similar do nothing to protect you. This is any web app. 

And XSS defense in a complex app is rough. Take the time to study it! I’m happy 
to present on XSS defense in-depth to the Oath standard body community if you 
wish. It’s a lot more difficult to get right than most think.

Once you have XSS, dang. Might as well just stick unsigned AT’s in URL’s.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 2:51 PM, Neil Madden <neil.mad...@forgerock.com> wrote:
> 
> Ha! Well it was Jim Manico’s pessimism about http-only cookies that started 
> it! :-)
> 
> I agree with Jim about http-only, and I agree with you that token binding has 
> lots of other good advantages. But pretty much all security is lost if XSS is 
> a possibility. Even storing secrets on the server does not help much as if I 
> can forge requests from the same origin then I can probably trick the server 
> into performing actions on my behalf too. Preventing/mitigating XSS is 
> crucial (CSP is a big help), but that is not specific to OAuth. 
> 
> — Neil
> 
> On Friday, May 18, 2018 at 6:46 pm, John Bradley <ve7...@ve7jtb.com> wrote:
> You cant extract a token bound cookie or AT and use it in a different user 
> agent.
> 
>  
> 
> You could still force the user agent to use a token bound cookie itself. 
> 
>  
> 
> For the AT and refresh they are not cookies so they need to sent by the JS so 
> may be harder to trigger?
> 
>  
> 
> I thought I was the pessimistic one
> 
>  
> 
> SPA may turn out to be impossible to completely secure.  However that wont 
> stop people from creating them.
> 
>  
> 
> We can try to put together the best advice, and limit the damage.
> 
>  
> 
> John B.
> 
>  
> 
> Sent from Mail for Windows 10
> 
>  
> 
> From: Neil Madden
> Sent: Friday, May 18, 2018 7:38 PM
> To: John Bradley; Jim Manico
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> 
>  
> 
> I might be missing something here, but aren’t bound tokens exactly as 
> vulnerable to the XSS attacks you describe as http-only cookies are? 
> 
>  
> 
> — Neil
> 
>  
> 
> On Friday, May 18, 2018 at 5:43 pm, Jim Manico <j...@manicode.com> wrote:
> 
> A few notes:
> 
> > The session cookie should also be flagged as http only to protect it.  
> 
>  
> 
> This provides no real protection. If I get XSS into your site I don’t need to 
> steal the cookie. I can just force requests that will automatically send it 
> (client side or stored request forgery). So while it’s a standard suggestion, 
> it helps little. 
> 
>  
> 
> > Having a refresh token in local storrage may introduce new security issues 
> > unless it is token bound.  
> 
>  
> 
> Token binding is not live yet, right? If you need to store a token in a 
> browser please note there is no safe place to store it. LocalStorage can be 
> harvested by XSS and even the strongest cookies can be replayed as discussed 
> above. I can’t wait for browser based token binding! But it will likely take 
> years for this to be avail in the majority of browsers.
> 
>  
> 
> > Understanding the security issues of the code flow in the browser is 
> > important, before any new recommendation.  
> 
>  
> 
> Well said. It looks to be the only secure workflow for browser based apps. 
> Love it how passwords are kept away from RP’s and high powered tokens are not 
> stored in the browser.
> 
>  
> 
> Aloha,
> 
> --
> 
> Jim Manico
> 
> @Manicode
> 
> Secure Coding Education
> 
> +1 (808) 652-3805
> 
> 
> On May 18, 2018, at 12:27 PM, John Bradley <ve7...@ve7jtb.com> wrote:
> 
> Yes that was the original intent to have the AT be short lived and refresh 
> the AT via the authorization endpoint based on the session cookie. 
> 
> The session cookie should also be flagged as http only to protect it. 
> 
> Having a refresh token in local storrage may introduce new security issues 
> unless it is token bound. 
> 
> Understanding the security issues of the code flow in the browser is 
> important, before any new recommendation. 
> 
> John B.
> 
> From: Brock Allen
> 
> Sent: Friday, May 18, 2:46 PM
> 
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> 
> To: David Waite, Hannes Tschofenig
> 
> Cc: oauth@ietf.org
> 
> 
> One thing I maybe should have listed in the pros/cons in my original email is 
> session manageme

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Jim Manico]

100% and that’s a good point. Stolen tokens will no longer work under token 
binding but XSS that does “stored request forgery” is still the bane of all web 
based apps.

No web app with XSS vulnerabilities is safe from “stored forged requests”, 
which means you really need to be bulletproof from XSS if you want secure web 
software. Token binding does not stop this at all.

So escape! Sanitize HTML input! Use safe JS sinks! Handle client side JSON 
correctly! CSP that app. These are critical defenses if you want security on 
the web.

Token binding helps if a token is stolen. It should no longer be effective or 
active when used in a different client.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 1:38 PM, Neil Madden <neil.mad...@forgerock.com> wrote:
> 
> I might be missing something here, but aren’t bound tokens exactly as 
> vulnerable to the XSS attacks you describe as http-only cookies are? 
> 
> — Neil
> 
> On Friday, May 18, 2018 at 5:43 pm, Jim Manico <j...@manicode.com> wrote:
> A few notes:
> 
> > The session cookie should also be flagged as http only to protect it.  
> 
> This provides no real protection. If I get XSS into your site I don’t need to 
> steal the cookie. I can just force requests that will automatically send it 
> (client side or stored request forgery). So while it’s a standard suggestion, 
> it helps little. 
> 
> > Having a refresh token in local storrage may introduce new security issues 
> > unless it is token bound.  
> 
> Token binding is not live yet, right? If you need to store a token in a 
> browser please note there is no safe place to store it. LocalStorage can be 
> harvested by XSS and even the strongest cookies can be replayed as discussed 
> above. I can’t wait for browser based token binding! But it will likely take 
> years for this to be avail in the majority of browsers.
> 
> > Understanding the security issues of the code flow in the browser is 
> > important, before any new recommendation.  
> 
> Well said. It looks to be the only secure workflow for browser based apps. 
> Love it how passwords are kept away from RP’s and high powered tokens are not 
> stored in the browser.
> 
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
>> On May 18, 2018, at 12:27 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>> 
>> Yes that was the original intent to have the AT be short lived and refresh 
>> the AT via the authorization endpoint based on the session cookie.  
>> 
>> The session cookie should also be flagged as http only to protect it.  
>> 
>> Having a refresh token in local storrage may introduce new security issues 
>> unless it is token bound.  
>> 
>> Understanding the security issues of the code flow in the browser is 
>> important, before any new recommendation.  
>> 
>> John B. 
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2:46 PM
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> To: David Waite, Hannes Tschofenig
>> Cc: oauth@ietf.org
>> 
>> 
>> One thing I maybe should have listed in the pros/cons in my original email 
>> is session management and token lifetime considerations, keeping in mind the 
>> original intent of the implicit flow. 
>> 
>> What I mean is that with implicit grant type, the client's ability to get 
>> new access tokens is limited to the user's session at the AS/OP. Obviously 
>> other flows make more sense to obtain longer lived access (via refresh 
>> tokens), but I don't know about a browser-based JS app. In a sense there's a 
>> bit of protection for the end user built into that design by virtue of being 
>> tied to the user's cookie at the AS/OP. 
>> 
>> Just throwing that out as an additional discussion point.
>> 
>> -Brock 
>> 
>>> On 5/18/2018 6:04:47 AM, David Waite <da...@alkaline-solutions.com> wrote:
>>> I have written some guidance already (in non-RFC format) on preferring code 
>>> for single page apps, and other security practices (CORS, CSP). From the AS 
>>> point of view, it aligns well with the native apps BCP. There are benefits 
>>> of thinking about native and SPA apps just as ‘public clients’ from a 
>>> policy/properties point of view. It also greatly simplifies OAuth/OIDC 
>>> support on both the AS administrator and client developer side when 
>>> converting web properties into native apps using technologies like Electron 
>>> or Cordova. 
>>> 
>>> For the later requirements in the list around token policy, I am not sure 
>>

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Jim Manico]

And I agree, Brock. CSP-3 policies that use strict-dynamic and nonces are 
fairly straight forward to deploy and provide backwards compatibility down to 
CSP 2 and 1. I yearn for a world where token binding and CSP are commonplace so 
I can sleep again! Until then, these solutions are fragile at best in the face 
of XSS.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 12:53 PM, Brock Allen <brockal...@gmail.com> wrote:
> 
> Fair enough, and I'm happy that this discussion has started. 
> 
> For now, IMO, CSP is a big help in protecting these types of apps. Token 
> binding will of course help too, once it's available/practical.
> 
> -Brock
> 
>> On 5/18/2018 12:47:49 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>> 
>> There are lots of issues with the current implicit flow around fragment 
>> encoding as well.
>> 
>>  
>> 
>> However moving the token used for refresh from being a HTTP only cookie to a 
>> refresh token available in the DOM makes me uncomfortable without having 
>> sufficient mitigations against XSS.
>> 
>>  
>> 
>> The current flow is vulnerable to  XSS for the AT, however if that is short 
>> lived it restricts the damage.
>> 
>>  
>> 
>> The better solution is token binding the AT and perhaps a RT. 
>> 
>>  
>> 
>> We need to start talking about it.  There are issues around potentially 
>> using service workers etc as well.
>> 
>>  
>> 
>> So we should start but I am not sure of what the correct answer is yet.
>> 
>>  
>> 
>> John B.
>> 
>>  
>> 
>> Sent from Mail for Windows 10
>> 
>>  
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2018 6:36 PM
>> To: John Bradley; David Waite; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>>  
>> 
>> It sounds to me as if you're hesitant to recommend code flow (at least for 
>> now) then for browser-based JS apps.
>> 
>>  
>> 
>> -Brock
>> 
>>  
>> 
>> On 5/18/2018 12:27:48 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>> 
>> Yes that was the original intent to have the AT be short lived and refresh 
>> the AT via the authorization endpoint based on the session cookie. 
>> 
>> The session cookie should also be flagged as http only to protect it. 
>> 
>> Having a refresh token in local storrage may introduce new security issues 
>> unless it is token bound. 
>> 
>> Understanding the security issues of the code flow in the browser is 
>> important, before any new recommendation. 
>> 
>> John B.
>> 
>> From: Brock Allen
>> 
>> Sent: Friday, May 18, 2:46 PM
>> 
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>> To: David Waite, Hannes Tschofenig
>> 
>> Cc: oauth@ietf.org
>> 
>> 
>> One thing I maybe should have listed in the pros/cons in my original email 
>> is session management and token lifetime considerations, keeping in mind the 
>> original intent of the implicit flow.
>> 
>> What I mean is that with implicit grant type, the client's ability to get 
>> new access tokens is limited to the user's session at the AS/OP. Obviously 
>> other flows make more sense to obtain longer lived access (via refresh 
>> tokens), but I don't know about a browser-based JS app. In a sense there's a 
>> bit of protection for the end user built into that design by virtue of being 
>> tied to the user's cookie at the AS/OP.
>> 
>> Just throwing that out as an additional discussion point.
>> 
>> -Brock
>> 
>> On 5/18/2018 6:04:47 AM, David Waite <da...@alkaline-solutions.com> wrote:
>> 
>> I have written some guidance already (in non-RFC format) on preferring code 
>> for single page apps, and other security practices (CORS, CSP). From the AS 
>> point of view, it aligns well with the native apps BCP. There are benefits 
>> of thinking about native and SPA apps just as ‘public clients’ from a 
>> policy/properties point of view. It also greatly simplifies OAuth/OIDC 
>> support on both the AS administrator and client developer side when 
>> converting web properties into native apps using technologies like Electron 
>> or Cordova.
>> 
>> For the later requirements in the list around token policy, I am not sure 
>> these are requirements for single page apps per se. I don’t believe the need 
>> for a policy using short

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Jim Manico]

> However moving the token used for refresh from being a HTTP only cookie to a 
> refresh token available in the DOM makes me uncomfortable without having 
> sufficient mitigations against XSS.

My conjecture is that it does not matter >>at all<< where you store tokens in 
relation to XSS. There is no secure place to store data in a browser in ways 
that cannot be abused by XSS. One XSS is complete compromise of the client. I’m 
happy to discuss in detail with POC’s offline if you like. HTTPOnly cookies do 
absolutely nothing to stop an attacker from leveraging XSS to forge requests 
through a victims browser, a much more common red team attack than trying to 
steal a cookie.

And XSS resistant apps are illusive. For example .NET is missing core controls 
around XSS defense like a well maintained HTML sanitizer for HTML input. 

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 12:53 PM, Brock Allen <brockal...@gmail.com> wrote:
> 
> Fair enough, and I'm happy that this discussion has started. 
> 
> For now, IMO, CSP is a big help in protecting these types of apps. Token 
> binding will of course help too, once it's available/practical.
> 
> -Brock
> 
>> On 5/18/2018 12:47:49 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>> 
>> There are lots of issues with the current implicit flow around fragment 
>> encoding as well.
>> 
>>  
>> 
>> However moving the token used for refresh from being a HTTP only cookie to a 
>> refresh token available in the DOM makes me uncomfortable without having 
>> sufficient mitigations against XSS.
>> 
>>  
>> 
>> The current flow is vulnerable to  XSS for the AT, however if that is short 
>> lived it restricts the damage.
>> 
>>  
>> 
>> The better solution is token binding the AT and perhaps a RT. 
>> 
>>  
>> 
>> We need to start talking about it.  There are issues around potentially 
>> using service workers etc as well.
>> 
>>  
>> 
>> So we should start but I am not sure of what the correct answer is yet.
>> 
>>  
>> 
>> John B.
>> 
>>  
>> 
>> Sent from Mail for Windows 10
>> 
>>  
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2018 6:36 PM
>> To: John Bradley; David Waite; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>>  
>> 
>> It sounds to me as if you're hesitant to recommend code flow (at least for 
>> now) then for browser-based JS apps.
>> 
>>  
>> 
>> -Brock
>> 
>>  
>> 
>> On 5/18/2018 12:27:48 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>> 
>> Yes that was the original intent to have the AT be short lived and refresh 
>> the AT via the authorization endpoint based on the session cookie. 
>> 
>> The session cookie should also be flagged as http only to protect it. 
>> 
>> Having a refresh token in local storrage may introduce new security issues 
>> unless it is token bound. 
>> 
>> Understanding the security issues of the code flow in the browser is 
>> important, before any new recommendation. 
>> 
>> John B.
>> 
>> From: Brock Allen
>> 
>> Sent: Friday, May 18, 2:46 PM
>> 
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>> To: David Waite, Hannes Tschofenig
>> 
>> Cc: oauth@ietf.org
>> 
>> 
>> One thing I maybe should have listed in the pros/cons in my original email 
>> is session management and token lifetime considerations, keeping in mind the 
>> original intent of the implicit flow.
>> 
>> What I mean is that with implicit grant type, the client's ability to get 
>> new access tokens is limited to the user's session at the AS/OP. Obviously 
>> other flows make more sense to obtain longer lived access (via refresh 
>> tokens), but I don't know about a browser-based JS app. In a sense there's a 
>> bit of protection for the end user built into that design by virtue of being 
>> tied to the user's cookie at the AS/OP.
>> 
>> Just throwing that out as an additional discussion point.
>> 
>> -Brock
>> 
>> On 5/18/2018 6:04:47 AM, David Waite <da...@alkaline-solutions.com> wrote:
>> 
>> I have written some guidance already (in non-RFC format) on preferring code 
>> for single page apps, and other security practices (CORS, CSP). From the AS 
>> point of view, it aligns well with the native apps BCP. There are benefits 
>> of thinking about native a

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

[Jim Manico]

A few notes:

> The session cookie should also be flagged as http only to protect it.  

This provides no real protection. If I get XSS into your site I don’t need to 
steal the cookie. I can just force requests that will automatically send it 
(client side or stored request forgery). So while it’s a standard suggestion, 
it helps little. 

> Having a refresh token in local storrage may introduce new security issues 
> unless it is token bound.  

Token binding is not live yet, right? If you need to store a token in a browser 
please note there is no safe place to store it. LocalStorage can be harvested 
by XSS and even the strongest cookies can be replayed as discussed above. I 
can’t wait for browser based token binding! But it will likely take years for 
this to be avail in the majority of browsers.

> Understanding the security issues of the code flow in the browser is 
> important, before any new recommendation.  

Well said. It looks to be the only secure workflow for browser based apps. Love 
it how passwords are kept away from RP’s and high powered tokens are not stored 
in the browser.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 12:27 PM, John Bradley <ve7...@ve7jtb.com> wrote:
> 
> Yes that was the original intent to have the AT be short lived and refresh 
> the AT via the authorization endpoint based on the session cookie.  
> 
> The session cookie should also be flagged as http only to protect it.  
> 
> Having a refresh token in local storrage may introduce new security issues 
> unless it is token bound.  
> 
> Understanding the security issues of the code flow in the browser is 
> important, before any new recommendation.  
> 
> John B. 
> 
> From: Brock Allen
> Sent: Friday, May 18, 2:46 PM
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> To: David Waite, Hannes Tschofenig
> Cc: oauth@ietf.org
> 
> 
> One thing I maybe should have listed in the pros/cons in my original email is 
> session management and token lifetime considerations, keeping in mind the 
> original intent of the implicit flow. 
> 
> What I mean is that with implicit grant type, the client's ability to get new 
> access tokens is limited to the user's session at the AS/OP. Obviously other 
> flows make more sense to obtain longer lived access (via refresh tokens), but 
> I don't know about a browser-based JS app. In a sense there's a bit of 
> protection for the end user built into that design by virtue of being tied to 
> the user's cookie at the AS/OP. 
> 
> Just throwing that out as an additional discussion point.
> 
> -Brock 
> 
>> On 5/18/2018 6:04:47 AM, David Waite <da...@alkaline-solutions.com> wrote:
>> I have written some guidance already (in non-RFC format) on preferring code 
>> for single page apps, and other security practices (CORS, CSP). From the AS 
>> point of view, it aligns well with the native apps BCP. There are benefits 
>> of thinking about native and SPA apps just as ‘public clients’ from a 
>> policy/properties point of view. It also greatly simplifies OAuth/OIDC 
>> support on both the AS administrator and client developer side when 
>> converting web properties into native apps using technologies like Electron 
>> or Cordova. 
>> 
>> For the later requirements in the list around token policy, I am not sure 
>> these are requirements for single page apps per se. I don’t believe the need 
>> for a policy using short-lived refresh tokens, revoking at signout, or use 
>> of the revocation endpoint are different from browser and native 
>> applications. Rather they seem to be a function of usage patterns that an AS 
>> may need to support, and we happen to sometimes associate those usage 
>> patterns with typical usage of native apps vs of browser apps. For example, 
>> browser login on a borrowed device can easily leak over to being app 
>> authorization - the authentication/authorization are web-based processes to 
>> achieve SSO.
>> 
>> I have been working on some guidance here around token lifetimes and 
>> policies, but I don’t know whether that brings in too much AS/OP business 
>> logic (and, likely implied product/deployment features) to be industry 
>> practices.
>> 
>> -DW
>> 
>>> On May 17, 2018, at 10:23 AM, Hannes Tschofenig <hannes.tschofe...@arm.com> 
>>> wrote:
>>> 
>>> Hi Brock,
>>>  
>>> there have been several attempts to start writing some guidance but so far 
>>> we haven’t gotten too far.
>>> IMHO it would be great to have a document.
>>>  
>>> Ciao
>>> Hannes
>>>  
>>> From: 

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

[Jim Manico]

If you plan on adding these web layer security suggestions into the OAuth 
standard I can think of 100-200 more requirements to add. I thought “do web 
security right” was an implied recommendation?

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Mar 20, 2018, at 5:37 AM, Brian Campbell <bcampb...@pingidentity.com> 
> wrote:
> 
> +1 to what Travis said about 3.8.1
> 
> The text in 3.8 about Open Redirection is new in this most recent -05 version 
> of the draft so this is really the first time it's been reviewed. I believe 
> 3.8..1 goes too far in saying "this draft recommends that every invalid 
> authorization request MUST NOT automatically redirect the user agent to the 
> client's redirect URI." 
> 
> I understand that text was informed by 
> https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 but it 
> takes one of the potential mitigation discussed there in section 3 (the one 
> which happens to contradict RFC 6749) and elevates it to a "MUST". I don't 
> think something that drastic is warranted. I think there are other 
> mitigations - like strict redirect_uri matching, referrer-policy headers, and 
> appending a dummy fragment on error redirects - that can protect against the 
> more serious redirection issues without -security-topics trying to introduce 
> normative breaking changes to the behavior from the original OAuth 2.0 
> Authorization Framework. 
> 
> Perhaps there are some error cases not mentioned in RFC 6749 where returning 
> an HTTP error code to the browser would be better or more appropriate than 
> redirecting back to the OAuth client (my opinion on this has gone in circles 
> and I'm honestly not sure anymore). But saying that authorization requests 
> never automatically redirect back to the client's redirect URI is excessive.
> 
> 
>> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <travis.spen...@curity.io> 
>> wrote:
>> I read through this doc and would like to share a bit of feedback in
>> hopes that it helps:
>> 
>> * There is no mention of Content Security Policy (CSP). This is a very
>> helpful security mechanism that all OAuth servers and web-based
>> clients should implement. I think this needs to be addressed in this
>> doc.
>> - No mention of frame breaking scripts for non-CSP aware user agents
>> -  No mention of X-Frame-Options
>> * There's no mention of HSTS which all OAuth servers and web-based
>> client should implement (or the reverse proxies in front of them
>> should)
>> * The examples only use 302 and don't mention that 303 is safer[1]
>>- Despite what it says in section 1.7 of RFC 6749, many people
>> think that a 302 is mandated by OAuth. It would be good to recommend a
>> 303 and use examples with other status codes.
>> * 3.3.1 refers to client.com in the example. This is a real domain.
>> Suggest client.example.com instead. Same issue in 3.1.2 where
>> client.evil.com is used
>> * 3.1.3 (proposed countermeasures) - native clients that use a web
>> server with a dynamic port should use dynamic client registration and
>> dynamic client management rather than allowing wildcards on the port
>> matching of the OAuth server.
>> * 3.8.1 says "Therefore this draft recommends that every invalid
>> authorization request MUST NOT automatically redirect the user agent
>> to the client's redirect URI" -- This is gonna break a lot of stuff
>> including other specs! I don't think that's warranted, and I am not
>> looking forward to the fallout this could cause.
>> 
>> Anyway, my $0.02. Hope it helps.
>> 
>> [1] https://arxiv.org/pdf/1601.01229v2.pdf
>> 
>> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <jos...@authlete.com> wrote:
>> > Hi Torsten,
>> >
>> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
>> > Redirector" could I think be made more explicit.
>> >
>> > Currently it explicitly mentions the invalid_request and invalid_scope
>> > errors must not redirect back to the client's registered redirect uri.
>> >
>> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
>> > potential errors that appear to fall into the same category. I understand 
>> > to
>> > block the attack fully we need 'must not redirect's for all the kinds of
>> > error that could cause an automatic redirect back to the client's 
>> > registered
>> > redirect uri without any user interaction - 'unauthorized_client' and
>> > 'unsupported_response_type' seem to fall into that category. 'server

Re: [OAUTH-WG] Recommendations for browser-based apps

[Jim Manico]

PS: The RFC for SameSite cookies has moved to here. 
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis

It's an approved standard and was rolled into the new cookie RFC.

Chrome support has a big impact on mobile and elsewhere. But I agree we need to 
see FireFox and Safari support and expect to see it within a year.

But that should not stop folks from using it today. It's backwards compatible 
with existing cookie behavior and is quite beautiful in it's
simplicity and power to defend against CSRF.

Aloha,
Jim

> On Sep 20, 2017, at 1:21 PM, Neil Madden <neil.mad...@forgerock.com> wrote:
> 
> Is this growing in support? It seems like a good idea, but when I reviewed it 
> recently the draft had expired almost a year ago and still only Chrome and 
> Opera had implemented it. From the outside it looks as if it has 
> (inexplicably) died. Do you know if there is some activity happening behind 
> the scenes?
> 
> -- Neil
> 
>> On 20 Sep 2017, at 02:31, Jim Manico <j...@manicode.com> wrote:
>> 
>> Not always, Bill. There is a new standard called "same site cookies" or 
>> "first party cookies" that allows you to programmatically remove this risk 
>> in some modern browsers, it's worth reviewing. 
>> 
>> https://tools.ietf.org/html/draft-west-first-party-cookies-07
>> 
>> It's live in Chrome and Opera and will only grow in support. 
>> http://caniuse.com/#search=samesite
>> 
>> Jim
>> 
>> 
>>> On Sep 20, 2017, at 8:44 AM, Bill Burke <bbu...@redhat.com> wrote:
>>> 
>>> Cookies are vulnerable to CXRF.
>>> 
>>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <mat...@gmail.com> wrote:
>>>> Why not using http-only cookies instead of refresh tokens?
>>>> If the app can interact with AuthZ server through a hidden iframe with
>>>> prompt=none param, you shouldn’t need refresh tokens.
>>>> 
>>>> If your SAP is running on a different domain with the backend server,
>>>> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
>>>> though.
>>>> 
>>>> On Sep 20, 2017, at 7:32, John Bradley <ve7...@ve7jtb.com> wrote:
>>>> 
>>>> Right,  Refresh token is bearer for native apps, that is why we came up 
>>>> with
>>>> PKCE to protect code.
>>>> 
>>>> For Angular the code flow with PKCE is probably better than the token
>>>> response type.
>>>> 
>>>> However with bearer tokens it is still riskier than code with a 
>>>> confidential
>>>> client so the AS should take that into account and not allow refresh tokens
>>>> to live forever.
>>>> 
>>>> One future way to protect refresh tokens and perhaps Access tokens is to 
>>>> use
>>>> token binding to bind the tokens to the user agent.   You could do that now
>>>> for refresh tokens in Edge (Chrome has TB off by default still).
>>>> 
>>>> I think more work needs to be done to come up with a best practice for SPA.
>>>> 
>>>> John B.
>>>> 
>>>> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.le...@motorolasolutions.com>
>>>> wrote:
>>>> 
>>>> Only for confidential clients.  No authentication is required for public
>>>> clients.
>>>> 
>>>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.h...@oracle.com>
>>>> wrote:
>>>>> 
>>>>> Except a refresh token is not purely bearer. The client is required to
>>>>> authenticate to use it.
>>>>> 
>>>>> Phil
>>>>> 
>>>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke <bbu...@redhat.com> wrote:
>>>>>> 
>>>>>> I'd be curious to the response to this too.
>>>>>> 
>>>>>> Seems to me that refresh token has the same possible security risks in
>>>>>> an Angular app as an access token, except the refresh token is valid
>>>>>> longerStill, if you did the implicit flow, you'd have to have
>>>>>> longer access token timeouts as it would be really annoying for the
>>>>>> user to have to login again and again in a long session with your
>>>>>> Angular app.
>>>>>> 
>>>>>> We have a javascript adapter that does Authz Code Flow with PKCE for
>>>>>> our Angular app.  It also does CORS checks on the code to token XHR
>>>>>&g

Re: [OAUTH-WG] Recommendations for browser-based apps

[Jim Manico]

While we did see android support in January 2017, Chrome and Opera only offered 
support a few months ago. FireFox has a bug on this with notes suggesting it 
will be rolled out in a year or so. And while the original RFC expired, it's 
being rolled into the cookie RFC per my understanding.

I also asked the author of this standard for additional commentary, I'll get 
back to you.

--
Jim Manico
@Manicode

> On Sep 20, 2017, at 1:21 PM, Neil Madden <neil.mad...@forgerock.com> wrote:
> 
> Is this growing in support? It seems like a good idea, but when I reviewed it 
> recently the draft had expired almost a year ago and still only Chrome and 
> Opera had implemented it. From the outside it looks as if it has 
> (inexplicably) died. Do you know if there is some activity happening behind 
> the scenes?
> 
> -- Neil
> 
>> On 20 Sep 2017, at 02:31, Jim Manico <j...@manicode.com> wrote:
>> 
>> Not always, Bill. There is a new standard called "same site cookies" or 
>> "first party cookies" that allows you to programmatically remove this risk 
>> in some modern browsers, it's worth reviewing. 
>> 
>> https://tools.ietf.org/html/draft-west-first-party-cookies-07
>> 
>> It's live in Chrome and Opera and will only grow in support. 
>> http://caniuse.com/#search=samesite
>> 
>> Jim
>> 
>> 
>>> On Sep 20, 2017, at 8:44 AM, Bill Burke <bbu...@redhat.com> wrote:
>>> 
>>> Cookies are vulnerable to CXRF.
>>> 
>>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <mat...@gmail.com> wrote:
>>>> Why not using http-only cookies instead of refresh tokens?
>>>> If the app can interact with AuthZ server through a hidden iframe with
>>>> prompt=none param, you shouldn’t need refresh tokens.
>>>> 
>>>> If your SAP is running on a different domain with the backend server,
>>>> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
>>>> though.
>>>> 
>>>> On Sep 20, 2017, at 7:32, John Bradley <ve7...@ve7jtb.com> wrote:
>>>> 
>>>> Right,  Refresh token is bearer for native apps, that is why we came up 
>>>> with
>>>> PKCE to protect code.
>>>> 
>>>> For Angular the code flow with PKCE is probably better than the token
>>>> response type.
>>>> 
>>>> However with bearer tokens it is still riskier than code with a 
>>>> confidential
>>>> client so the AS should take that into account and not allow refresh tokens
>>>> to live forever.
>>>> 
>>>> One future way to protect refresh tokens and perhaps Access tokens is to 
>>>> use
>>>> token binding to bind the tokens to the user agent.   You could do that now
>>>> for refresh tokens in Edge (Chrome has TB off by default still).
>>>> 
>>>> I think more work needs to be done to come up with a best practice for SPA.
>>>> 
>>>> John B.
>>>> 
>>>> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.le...@motorolasolutions.com>
>>>> wrote:
>>>> 
>>>> Only for confidential clients.  No authentication is required for public
>>>> clients.
>>>> 
>>>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.h...@oracle.com>
>>>> wrote:
>>>>> 
>>>>> Except a refresh token is not purely bearer. The client is required to
>>>>> authenticate to use it.
>>>>> 
>>>>> Phil
>>>>> 
>>>>>> On Sep 19, 2017, at 2:33 PM, Bill Burke <bbu...@redhat.com> wrote:
>>>>>> 
>>>>>> I'd be curious to the response to this too.
>>>>>> 
>>>>>> Seems to me that refresh token has the same possible security risks in
>>>>>> an Angular app as an access token, except the refresh token is valid
>>>>>> longerStill, if you did the implicit flow, you'd have to have
>>>>>> longer access token timeouts as it would be really annoying for the
>>>>>> user to have to login again and again in a long session with your
>>>>>> Angular app.
>>>>>> 
>>>>>> We have a javascript adapter that does Authz Code Flow with PKCE for
>>>>>> our Angular app.  It also does CORS checks on the code to token XHR
>>>>>> request just in case on the IDP side.
>>>>>> 
>>>>>>> On Tue, Se

Re: [OAUTH-WG] Recommendations for browser-based apps

[Jim Manico]

Not always, Bill. There is a new standard called "same site cookies" or "first 
party cookies" that allows you to programmatically remove this risk in some 
modern browsers, it's worth reviewing. 

https://tools.ietf.org/html/draft-west-first-party-cookies-07

It's live in Chrome and Opera and will only grow in support. 
http://caniuse.com/#search=samesite

Jim


> On Sep 20, 2017, at 8:44 AM, Bill Burke  wrote:
> 
> Cookies are vulnerable to CXRF.
> 
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>> Why not using http-only cookies instead of refresh tokens?
>> If the app can interact with AuthZ server through a hidden iframe with
>> prompt=none param, you shouldn’t need refresh tokens.
>> 
>> If your SAP is running on a different domain with the backend server,
>> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
>> though.
>> 
>> On Sep 20, 2017, at 7:32, John Bradley  wrote:
>> 
>> Right,  Refresh token is bearer for native apps, that is why we came up with
>> PKCE to protect code.
>> 
>> For Angular the code flow with PKCE is probably better than the token
>> response type.
>> 
>> However with bearer tokens it is still riskier than code with a confidential
>> client so the AS should take that into account and not allow refresh tokens
>> to live forever.
>> 
>> One future way to protect refresh tokens and perhaps Access tokens is to use
>> token binding to bind the tokens to the user agent.   You could do that now
>> for refresh tokens in Edge (Chrome has TB off by default still).
>> 
>> I think more work needs to be done to come up with a best practice for SPA.
>> 
>> John B.
>> 
>> On Sep 19, 2017, at 7:02 PM, Adam Lewis 
>> wrote:
>> 
>> Only for confidential clients.  No authentication is required for public
>> clients.
>> 
>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>> wrote:
>>> 
>>> Except a refresh token is not purely bearer. The client is required to
>>> authenticate to use it.
>>> 
>>> Phil
>>> 
 On Sep 19, 2017, at 2:33 PM, Bill Burke  wrote:
 
 I'd be curious to the response to this too.
 
 Seems to me that refresh token has the same possible security risks in
 an Angular app as an access token, except the refresh token is valid
 longerStill, if you did the implicit flow, you'd have to have
 longer access token timeouts as it would be really annoying for the
 user to have to login again and again in a long session with your
 Angular app.
 
 We have a javascript adapter that does Authz Code Flow with PKCE for
 our Angular app.  It also does CORS checks on the code to token XHR
 request just in case on the IDP side.
 
> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer 
> wrote:
> Hi,
> 
> there were some discussions in January regarding recommendations for
> browser-based apps
> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
> 
> I'd just like to ask if the Authorization Code Flow with PKCE is a
> valid
> option for Single-Page-Applications (in our case Angular), because
> Implicit
> Flow cannot be used in our scenario.
> 
> Authorization Code Flow with PKCE eliminates the necessity for client
> secrets, but our concern is that exposing the refresh token to the SPA
> might
> be a security risk, compared to the Implicit Flow were no refresh token
> is
> exposed.
> 
> What's your take on this?
> 
> Kind regards,
> Stefan Büringer
> 
> P.S. I couldn't find that much on the internet regarding Authorization
> Code
> Flow with PKCE in SPAs, if you have some recommendations for good blog
> posts
> I would be grateful.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
 
 
 
 --
 Bill Burke
 Red Hat
 
 ___
 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
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> 

Re: [OAUTH-WG] Recommendations for browser-based apps

[Jim Manico]

One of the reasons I see so many security folk discouraging implicit in web 
applications (like your Angular scenario) is because even though refresh tokens 
and similar require authentication, how do you store that info securely in a 
browser? One XSS and it's http://m.youtube.com/watch?v=dsx2vdn7gpY

- Jim

> On Sep 20, 2017, at 5:47 AM, Phil Hunt (IDM)  wrote:
> 
> Except a refresh token is not purely bearer. The client is required to 
> authenticate to use it. 
> 
> Phil
> 
>> On Sep 19, 2017, at 2:33 PM, Bill Burke  wrote:
>> 
>> I'd be curious to the response to this too.
>> 
>> Seems to me that refresh token has the same possible security risks in
>> an Angular app as an access token, except the refresh token is valid
>> longerStill, if you did the implicit flow, you'd have to have
>> longer access token timeouts as it would be really annoying for the
>> user to have to login again and again in a long session with your
>> Angular app.
>> 
>> We have a javascript adapter that does Authz Code Flow with PKCE for
>> our Angular app.  It also does CORS checks on the code to token XHR
>> request just in case on the IDP side.
>> 
>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer  
>>> wrote:
>>> Hi,
>>> 
>>> there were some discussions in January regarding recommendations for
>>> browser-based apps
>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>>> 
>>> I'd just like to ask if the Authorization Code Flow with PKCE is a valid
>>> option for Single-Page-Applications (in our case Angular), because Implicit
>>> Flow cannot be used in our scenario.
>>> 
>>> Authorization Code Flow with PKCE eliminates the necessity for client
>>> secrets, but our concern is that exposing the refresh token to the SPA might
>>> be a security risk, compared to the Implicit Flow were no refresh token is
>>> exposed.
>>> 
>>> What's your take on this?
>>> 
>>> Kind regards,
>>> Stefan Büringer
>>> 
>>> P.S. I couldn't find that much on the internet regarding Authorization Code
>>> Flow with PKCE in SPAs, if you have some recommendations for good blog posts
>>> I would be grateful.
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> 
>> 
>> -- 
>> Bill Burke
>> Red Hat
>> 
>> ___
>> 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] Redirection in authorization code flow: GET vs POST

[Jim Manico]

> Rejecting a GET with code in the URL means that the code is never
"used" at the AS, so can still be exchanged for an access token; and
rejecting the request does not mean it won't leak

That's a good point Thomas. I still think secure OAuth workflows should
totally avoid putting any kind of sensitive data in URI's for any step,
including POST /Actions/ that leak like a GET query parameter.

> So reject if you like from the user's point of view, but "consume" the
code anyway (and then immediately revoke the token, maybe), or you're
probably making things worse

Interesting point, but I think if the standard reflected this suggestion
it would be less likely that implementer will do it.

> (if you're worried of leaking 5min one-time codes, particularly when that 
> code cannot be used without a client_secret
and/or PKCE code_verifier)

Also a good point. This specific step in the workflow might not be at
risk as much as other steps, but I see a LOT of folks putting sensitive
data in tokens and I'm trying to help avoid that leakage.

Thanks for your feedback.

Aloha, Jim


On 8/13/17 11:20 AM, Thomas Broyer wrote:
> Rejecting a GET with code in the URL means that the code is never
> "used" at the AS, so can still be exchanged for an access token; and
> rejecting the request does not mean it won't leak. So reject if you
> like from the user's point of view, but "consume" the code anyway (and
> then immediately revoke the token, maybe), or you're probably making
> things worse (if you're worried of leaking 5min one-time codes,
> particularly when that code cannot be used without a client_secret
> and/or PKCE code_verifier)
>
> Disclaimer: not a security expert here.
>
> Le sam. 12 août 2017 16:55, Jim Manico <j...@manicode.com
> <mailto:j...@manicode.com>> a écrit :
>
> > The _*safest*_ thing for a client is to accept both. 
>
> I politely (and strongly) disagree with this statement. The safest
> thing for a client is to only accept POST or other verbs where any
> kind of sensitive data is NOT kept in the URL. Sensitive data in
> URL's leak like a sieve, even over HTTPS.
>
> Respectfully,
> Jim
>
>
>
> On 8/11/17 3:18 PM, John Bradley wrote:
>> OpenID Connect formally defined a POST response mode.
>>
>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>
>> The OAuth 2 spec docent preclude it.  
>>
>> The safest thing for a client is to accept both.  
>> The main advantages of POST is that it docent leak in the
>> referrer, and can handle larger responses without the browser
>> choking in some cases.
>>
>> Size is more of an issue in Connect where a id_token may be
>> returned in the front channel and POST allows for the larger
>> response without the client needing to have JS extract the fragment.
>>
>> That is why Connect defined it and OAuth largely assumes that for
>> code get is OK.
>> For security GET responses should add headers to prevent referrer
>> from leaking the code.
>>
>> We are adding advice on that to the Security document that is
>> being updated now.
>>
>> John B.
>>
>>
>>> On Aug 11, 2017, at 4:08 PM, Josh Mandel <jman...@gmail.com
>>> <mailto:jman...@gmail.com>> wrote:
>>>
>>> Fixing my "with this technique" url: it should have been
>>> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
>>>
>>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jman...@gmail.com
>>> <mailto:jman...@gmail.com>> wrote:
>>>
>>> Hi All,
>>>
>>> I've just encountered a server that performs a redirect
>>> (back to the client's redirect_uri) via POST instead of GET.
>>> This was surprising behavior to me and broke my client
>>> implementation — but citing chapter and verse, the server
>>> developer pointed out
>>> that https://tools.ietf.org/html/rfc6749#section-1.7 says 
>>>
>>> While the examples in this specification show the use of
>>> the HTTP 302 status code, any other method available via
>>> the user-agent to accomplish this redirection is allowed
>>> and is considered to be an implementation detail.
>>>
>>>
>>> Is triggering a POST-based redirect (e.g. with this
>>> technique
>>> 
>>> <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ff

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

[Jim Manico]

> Get is mostly OK with the correct headers to stop referrer leakage.

Those work in new-ish browsers only. Referrer is only one GET leakage vector.

>  Fragment should only be used with real JS clients in the browser and not 
> with servers.  

Fragment behavior is very different in modern browsers, which is one reason why 
many security folks recommend against the implicit grant type. (I'll double 
check on this one)

Respectfully,
--
Jim Manico
@Manicode

> On Aug 12, 2017, at 11:43 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> 
> From a interoperability perspective accepting both is best.   
> 
> Get is mostly OK with the correct headers to stop referer leakage.   Fragment 
> should only be used with real JS clients in the browser and not with servers. 
>  
> 
> That is the general direction of the new security advice.  
> 
> People wanting to use POST should probably follow the connect spec for 
> response mode to be explicit about it.  
> 
> John B. 
> 
>> On Aug 12, 2017 10:55, "Jim Manico" <j...@manicode.com> wrote:
>> > The safest thing for a client is to accept both.  
>> I politely (and strongly) disagree with this statement. The safest thing for 
>> a client is to only accept POST or other verbs where any kind of sensitive 
>> data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even 
>> over HTTPS.
>> 
>> Respectfully,
>> Jim
>> 
>> 
>>> On 8/11/17 3:18 PM, John Bradley wrote:
>>> OpenID Connect formally defined a POST response mode.
>>> 
>>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>> 
>>> The OAuth 2 spec docent preclude it.  
>>> 
>>> The safest thing for a client is to accept both.  
>>> The main advantages of POST is that it docent leak in the referrer, and can 
>>> handle larger responses without the browser choking in some cases.
>>> 
>>> Size is more of an issue in Connect where a id_token may be returned in the 
>>> front channel and POST allows for the larger response without the client 
>>> needing to have JS extract the fragment.
>>> 
>>> That is why Connect defined it and OAuth largely assumes that for code get 
>>> is OK.
>>> For security GET responses should add headers to prevent referrer from 
>>> leaking the code.
>>> 
>>> We are adding advice on that to the Security document that is being updated 
>>> now.
>>> 
>>> John B.
>>> 
>>> 
>>>> On Aug 11, 2017, at 4:08 PM, Josh Mandel <jman...@gmail.com> wrote:
>>>> 
>>>> Fixing my "with this technique" url: it should have been 
>>>> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
>>>> 
>>>>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jman...@gmail.com> wrote:
>>>>> Hi All,
>>>>> 
>>>>> I've just encountered a server that performs a redirect (back to the 
>>>>> client's redirect_uri) via POST instead of GET. This was surprising 
>>>>> behavior to me and broke my client implementation — but citing chapter 
>>>>> and verse, the server developer pointed out that 
>>>>> https://tools.ietf.org/html/rfc6749#section-1.7 says 
>>>>> 
>>>>>> While the examples in this specification show the use of the HTTP 302 
>>>>>> status code, any other method available via the user-agent to accomplish 
>>>>>> this redirection is allowed and is considered to be an implementation 
>>>>>> detail.
>>>>> 
>>>>> Is triggering a POST-based redirect (e.g. with this technique) to the 
>>>>> redirect_url (including url query parameters for state and code) indeed 
>>>>> considered a "method available via the user-agent to accomplish this 
>>>>> redirection"? In other words, should a well-behaved OAuth client be 
>>>>> prepared to receive GETs as well as POSTs to its redirect_uri? If so, 
>>>>> what would be the considerations for a server choosing between GET and 
>>>>> POST?
>>>>> 
>>>>> Best,
>>>>> 
>>>>>   Josh
>>>> 
>>>> ___
>>>> 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
>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.manicode.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

[Jim Manico]

> The _*safest*_ thing for a client is to accept both. 

I politely (and strongly) disagree with this statement. The safest thing
for a client is to only accept POST or other verbs where any kind of
sensitive data is NOT kept in the URL. Sensitive data in URL's leak like
a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM, John Bradley wrote:
> OpenID Connect formally defined a POST response mode.
>
> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>
> The OAuth 2 spec docent preclude it.  
>
> The safest thing for a client is to accept both.  
> The main advantages of POST is that it docent leak in the referrer,
> and can handle larger responses without the browser choking in some cases.
>
> Size is more of an issue in Connect where a id_token may be returned
> in the front channel and POST allows for the larger response without
> the client needing to have JS extract the fragment.
>
> That is why Connect defined it and OAuth largely assumes that for code
> get is OK.
> For security GET responses should add headers to prevent referrer from
> leaking the code.
>
> We are adding advice on that to the Security document that is being
> updated now.
>
> John B.
>
>
>> On Aug 11, 2017, at 4:08 PM, Josh Mandel <jman...@gmail.com
>> <mailto:jman...@gmail.com>> wrote:
>>
>> Fixing my "with this technique" url: it should have been
>> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
>>
>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jman...@gmail.com
>> <mailto:jman...@gmail.com>> wrote:
>>
>> Hi All,
>>
>> I've just encountered a server that performs a redirect (back to
>> the client's redirect_uri) via POST instead of GET. This was
>> surprising behavior to me and broke my client implementation —
>> but citing chapter and verse, the server developer pointed out
>> that https://tools.ietf.org/html/rfc6749#section-1.7
>> <https://tools.ietf.org/html/rfc6749#section-1.7> says 
>>
>> While the examples in this specification show the use of the
>> HTTP 302 status code, any other method available via the
>> user-agent to accomplish this redirection is allowed and is
>> considered to be an implementation detail.
>>
>>
>> Is triggering a POST-based redirect (e.g. with this technique
>> <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63%29>)
>> to the redirect_url (including url query parameters for state and
>> code) indeed considered a "method available via the user-agent to
>> accomplish this redirection"? In other words, should a
>> well-behaved OAuth client be prepared to receive GETs as well as
>> POSTs to its redirect_uri? If so, what would be the
>> considerations for a server choosing between GET and POST?
>>
>>     Best,
>>
>>   Josh
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

[Jim Manico]

I would take it a step further. GET's leak parameters even over HTTPS. I advise 
all GET based OAuth communication to be switched to POST, a much more security 
centric verb.

Aloha,
--
Jim Manico

> On Aug 11, 2017, at 3:08 PM, Josh Mandel <jman...@gmail.com> wrote:
> 
> Fixing my "with this technique" url: it should have been 
> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
> 
>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jman...@gmail.com> wrote:
>> Hi All,
>> 
>> I've just encountered a server that performs a redirect (back to the 
>> client's redirect_uri) via POST instead of GET. This was surprising behavior 
>> to me and broke my client implementation — but citing chapter and verse, the 
>> server developer pointed out that 
>> https://tools.ietf.org/html/rfc6749#section-1.7 says 
>> 
>>> While the examples in this specification show the use of the HTTP 302 
>>> status code, any other method available via the user-agent to accomplish 
>>> this redirection is allowed and is considered to be an implementation 
>>> detail.
>> 
>> Is triggering a POST-based redirect (e.g. with this technique) to the 
>> redirect_url (including url query parameters for state and code) indeed 
>> considered a "method available via the user-agent to accomplish this 
>> redirection"? In other words, should a well-behaved OAuth client be prepared 
>> to receive GETs as well as POSTs to its redirect_uri? If so, what would be 
>> the considerations for a server choosing between GET and POST?
>> 
>> Best,
>> 
>>   Josh
> 
> ___
> 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 BCP on Compression in JWE

[Jim Manico]

This looks like a very reasonable and fairly achievable security defense
feature.

So would you suggest that the core JWE standard provide clear guidance
to library authors about when to use compression? Would you also suggest
that we need additional flags on JWT elements that do or do not need to
be compressed so libraries can selectively compress JWT?

We can't fix the past but we can certainly provide more targeted advice
as to how to handle this risk. I'd be glad to help.

- Jim



On 7/29/17 10:22 AM, Yaron Sheffer wrote:
> Hi Jim,
>
> The problem is not the encryption of attacker-controlled data. The
> problem is the interaction between this encryption and compression.
>
> If you don't need compression, you're good. You're mostly OK if you
> can compress only the non-attacker controlled data, however this could
> potentially leak information about ciphertext.
>
> This is all very use-case specific and fragile, so I think a
> reasonable recommendation is:
>
> - Avoid transparent compression in generic JWS/JWE libraries.
> - Only compress data at the application layer, but bear in mind that
> the length of compressed+encrypted data leaks information about
> cleartext.
>
> Thanks,
> Yaron
>
> On 29/07/17 21:32, Jim Manico wrote:
>> Yaron,
>>
>> As a developer, I can think of many scenarios where the attacker
>> controls some of the plaintext yet I still need encryption services
>> of some kind. What are the proper crypto controls that allow
>> developers to do this safely? I think that's the better question
>> right now.
>>
>> Aloha,
>> -- 
>> Jim Manico
>> @Manicode
>>
>>> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer <yaronf.i...@gmail.com>
>>> wrote:
>>>
>>> Hi Brian,
>>>
>>> These two attacks on TLS are only examples of the breakage that can
>>> occur when the adversary can control the plaintext to some degree
>>> (even a small piece of the plaintext, e.g. a malleable HTTP cookie
>>> can result in decryption of the whole message). Similar attacks were
>>> demonstrated in IPsec. Can you please add details on why typical use
>>> of JWT would not be susceptible to these attacks?
>>>
>>> Thanks,
>>> Yaron
>>>
>>>> On critique of JWT I've seen a few times can be paraphrased as "JWT
>>>> supports compressed plaintext so, because of CRIME and BREACH, it is
>>>> dangerous and stupid."  It's very possible that I am stupid (many
>>>> on this
>>>> list will likely attest to it) but I don't see the applicability of
>>>> those
>>>> kinds of chosen plaintext attacks aimed at recovering sensitive
>>>> data to how
>>>> JWT/JWE are typically used.
>>>>
>>>> I think it would be useful, if during the development of the JWT
>>>> BCP, the
>>>> authors or chairs or WG could somehow engage some experts (CFRG?) to
>>>> understand if there's any real practical advice that can be given
>>>> about
>>>> using compression with JWE and the risks involved.
>>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com


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

Re: [OAUTH-WG] JWT BCP on Compression in JWE

[Jim Manico]

Yaron,

As a developer, I can think of many scenarios where the attacker controls some 
of the plaintext yet I still need encryption services of some kind. What are 
the proper crypto controls that allow developers to do this safely? I think 
that's the better question right now.

Aloha,
--
Jim Manico
@Manicode

> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> 
> Hi Brian,
> 
> These two attacks on TLS are only examples of the breakage that can occur 
> when the adversary can control the plaintext to some degree (even a small 
> piece of the plaintext, e.g. a malleable HTTP cookie can result in decryption 
> of the whole message). Similar attacks were demonstrated in IPsec. Can you 
> please add details on why typical use of JWT would not be susceptible to 
> these attacks?
> 
> Thanks,
>Yaron
> 
>> On critique of JWT I've seen a few times can be paraphrased as "JWT
>> supports compressed plaintext so, because of CRIME and BREACH, it is
>> dangerous and stupid."  It's very possible that I am stupid (many on this
>> list will likely attest to it) but I don't see the applicability of those
>> kinds of chosen plaintext attacks aimed at recovering sensitive data to how
>> JWT/JWE are typically used.
>> 
>> I think it would be useful, if during the development of the JWT BCP, the
>> authors or chairs or WG could somehow engage some experts (CFRG?) to
>> understand if there's any real practical advice that can be given about
>> using compression with JWE and the risks involved.
>> 
> 
> ___
> 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: JSON Web Token Best Current Practices

[Jim Manico]

I support adoption of this document.

Aloha, Jim


On 7/20/17 2:37 AM, Rifaat Shekh-Yusef wrote:
> All,
>
> We would like to get a confirmation on the mailing list for the
> adoption of the *JSON Web Token Best Current Practices* as a WG document
> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/
> 
>
> Please, let us know if you support or object to the adoption of 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] Second OAuth Security Workshop (Call for Papers)

[Jim Manico]

I'd love to attend.

1) Can you handle remote participants?
2) Any chance you want to move this to Hawaii? I can host the work space. 
Seriously.

Aloha,
--
Jim Manico
@Manicode

> On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt <tors...@lodderstedt.net> 
> wrote:
> 
> Hi all,
> 
> I'm pleased to announce the hosts managed to change the date of the security 
> workshop to the end of the week before IETF-99, July 13-14. 
> 
> Please find the updated CfP below.
> 
> kind regards,
> Torsten.
> 
> ===
> 
> C a l l F o r P a p e r s
> 
> Second OAuth Security Workshop (OSW 2017)
> 
> Zurich, Switzerland -- July 13-14, 2017 (note the changed event date)
> 
> WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/
> 
> Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
> 
> ===
> 
> Overview
> 
> The OAuth Security Workshop (OSW) focuses on improving security of the
> OAuth standard and related Internet protocols. This workshop brings
> together the IETF OAuth Working Group and security experts from
> research, industry, and standardization to this end. The workshop is
> hosted by the Zurich Information Security and Privacy Center at ETH Zurich.
> 
> While the standardization process of OAuth ensures extensive reviews
> (both security and non-security related), further analysis by security
> experts from academia and industry is essential to ensure high quality
> specifications. Contributions to this workshop can help to improve the
> security of the Web and the Internet.
> 
> 
> Scope
> 
> We seek position papers related to the security of OAuth, OpenID
> Connect, and other technologies using OAuth under the hood.
> Contributions regarding technologies that are used in OAuth, such as
> JOSE, or impact the security of OAuth, such as Web technology, are also
> welcome.
> 
> 
> Important Dates
> 
> Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
> Author notification: May 15, 2017.
> Registration deadline: June 16, 2017.
> Workshop: July 13 and July 14, 2017.
> 
> 
> Invited Speakers
> 
> Cas Cremers, University of Oxford
> 
> 
> Submission
> 
> We welcome position papers that describe existing work, raise new
> requirements, highlight challenges, write-ups of implementation and
> deployment experience, lessons-learned from successful or failed
> attempts, and ideas on how to improve OAuth and OAuth extensions.
> 
> Position papers submitted to the OAuth Security Workshop may report on
> (unpublished) work in progress, be submitted to other places, and may
> even have already appeared or been accepted elsewhere.
> 
> Submissions must be in PDF format and should feature reasonable margins
> and formatting. There is no page limit, but the submission should be
> brief (ideally not more than 3-5 pages). Submissions should not be
> anonymized.
> 
> Submission Website: https://easychair.org/conferences/?conf=osw17
> 
> 
> Publication and Presentation
> 
> One of the authors of the accepted position paper is expected to present
> the paper at the workshop.
> 
> All presentations and papers will be put online but there will be no
> formal proceedings. Authors of accepted papers will have the option to
> revise their papers before they are put online.
> 
> 
> IPR Policy
> 
> The workshop will have no expectation of IPR disclosure or licensing
> related to its submissions. Authors are responsible for obtaining
> appropriate publication clearances.
> 
> 
> Program Committee
> 
> Chairs
> David Basin (ETH Zurich)
> Torsten Lodderstedt (YES Europe)
> 
> Members
> John Bradley (Ping Identity)
> Ralf Küsters (University of Stuttgart)
> Chris Mitchell (Royal Holloway University of London)
> Anthony Nadalin (Microsoft)
> Nat Sakimura (Nomura Research Institute)
> Ralf Sasse (ETH Zurich)
> Jörg Schwenk (Ruhr University Bochum)
> Hannes Tschofenig (IETF OAuth Working Group Co-Chair)
> 
>> Am 13.03.2017 um 21:01 schrieb John Bradley <ve7...@ve7jtb.com>:
>> 
>> I did point out earlier when I discovered the dates, that I similarly asked 
>> for it to be later in the week.
>> It is probably fine for Europeans but it will stop many people from being 
>> able to attend including myself unless I can come up with other meetings in 
>> Europe to fill those days.
>> 
>> If we cant move it then we will have to live with it and attend or not.
>> 
>> John B.
>> 
>>> On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt <tors..

Re: [OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri

[Jim Manico]

From a security POV please force HTTPS as we see in 5.2.1. The only performance 
problem with HTTPS is that it's not used enough. There is no good reason for a 
security framework to support HTTP.

Aloha,
Jim

> On Mar 24, 2017, at 9:15 AM, Dave Tonge  wrote:
> 
> Hi Nat and John
> 
> I have some questions re the JWT Secured Authorization Request spec
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12
> 
> 1. Does the request_uri always have to be an URL? 
> If the request object is hosted by the client then it makes sense, but if 
> 10.3.d is followed and the AS provides an endpoint where the client can 
> exchange a request object for a "Request Object URI" then it would seem 
> acceptable for that uri to be an urn. Only the AS would need to be able to 
> fetch the request object and therefore there would be no need for the request 
> object to be made available via https.
> 
> 2. Should the mechanism described in 10.3.d be explained in 5.2?
> I think that 10.3.d could be widely used as it solves a number of problems - 
> however it is currently not clearly defined in either OIDC Core or jwsreq. 
> 
> 3. The spec seems inconsistent on the use of HTTPS
> Subject to any discussion re request_uris always being urls, there seems to 
> be an inconsistency between 5.2 and 5.2.1 
> 
> 5.2: 
>  The scheme used in the "request_uri" value MUST be "https",
>unless the target Request Object is signed in a way that is
>verifiable by the Authorization Server.
> 
> 5.2.1
> The Client stores the Request Object resource either locally or
>remotely at a URL the Authorization Server can access.  The URL MUST
>be HTTPS URL.  This URL is the Request Object URI, "request_uri".
> 
> 
> Thanks
> 
> -- 
> Dave Tonge
> CTO, Momentum Financial Technology
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Binding Presentations?

[Jim Manico]

Brian (and John),

Thank you both for the references. Perfect.

Aloha, Jim


On 3/17/17 12:10 PM, Brian Campbell wrote:
> Dirk gave this preso nearly 2 years ago
> https://www.slideshare.net/CloudIDSummit/cis-2015-intro-to-token-binding-over-http-cis-2015
> <https://www.slideshare.net/CloudIDSummit/cis-2015-intro-to-token-binding-over-http-cis-2015>
> which is out of date but has the main concepts, I think. There's also
> this http://www.browserauth.net/token-binding
> <http://www.browserauth.net/token-binding> page by him.
>
> I'm planing on a doing a presentation on Token Binding at CIS
> <https://www.cloudidentitysummit.com> this summer. But that's not
> until June and none of the content exists yet.
>
> Otherwise the draft specs are probably the best bet at this point. And
> they are all still in draft, though some are more stable than others,
> they may still change.
>
> Token Binding:
> https://tools.ietf.org/html/draft-ietf-tokbind-https-08
> https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13
> https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07
>
> Application in OAuth:
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-02
>
> Application in OpenID Connect:
> http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html
>
>
>
>
> On Fri, Mar 17, 2017 at 9:09 AM, Jim Manico <j...@manicode.com
> <mailto:j...@manicode.com>> wrote:
>
> Hello OAuthers,
>
> I'm trying to get my head around token binding beyond the RFC. Are
> there any presentations or other media on token binding that any
> of you are aware of? My google-fu is coming up empty.
>
> Thanks and Aloha,
> - Jim
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

[OAUTH-WG] Token Binding Presentations?

[Jim Manico]

Hello OAuthers,

I'm trying to get my head around token binding beyond the RFC. Are there any 
presentations or other media on token binding that any of you are aware of? My 
google-fu is coming up empty.

Thanks and Aloha,
- Jim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] SPA applications best practice

[Jim Manico]

I've been collecting opinions about the best OAuth2 workflows for SPA 
applications and have come up with the following basic recommendations.

1) The more secure flow is going to be authorization code. Keep access tokens 
out of the DOM/Browser history.

2) Implicit flows are your only choice if you allow serverless JS clients to 
access your OAuth endpoints. This is much easier to implement but carries a 
great deal more risk. Wether or not this is good for you depends on your threat 
model and risk tolerance. 

I'd love to keep going and turn this into a RFC but this is over my head. Does 
anyone here with more experience care to assist in proposing a SPA-OAuth RFC? 
I'd be happy to help with the grunt work. This is one of the main areas of 
OAuth where answers are fractured and I'd love to help push more clarity here.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

> 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
> <mailto: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 <j...@manicode.com
>> <mailto:j...@manicode.com>> 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
>> <mailto: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 <mailto: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=DwMD-g=q3cDpHe1hF8lXU5EFjNM_A=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s=YExyuyZO5YNpSvS3mEUG5pjKAjRXXVT8Xvk8hIb-Efw=>
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> 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=DwMD-g=q3cDpHe1hF8lXU5EFjNM_A=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s=_Mig-zmCt1y9dZpCece1dqby3VmcZVOu2JPcmAwzwKU=>
>>>
>>> Isn't this generally dis

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

[Jim Manico]

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

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

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

[Jim Manico]

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.

https://developers.google.com/identity/protocols/OAuth2UserAgent

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

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

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[Jim Manico]

I'm just some random idiot am an not in this working group but the work
from
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
<https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00>
is one of the most up to date and useful OAuth security resources every
published. I am thrilled to see more work put into it.

Aloha, Jim


On 2/3/17 1:57 PM, William Denniss wrote:
> I support the adoption of this document as a working group item.
>
> On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke <j...@willeke.com
> <mailto:j...@willeke.com>> wrote:
>
> +! 
> I agree this is needed.
>
> --
> -jim
> Jim Willeke
>
> On Thu, Feb 2, 2017 at 4:33 PM, John Bradley <ve7...@ve7jtb.com
> <mailto:ve7...@ve7jtb.com>> wrote:
>
> I am in favour of adoption.
> > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig
> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>
> wrote:
> >
> > Hi all,
> >
> > this is the call for adoption of the 'OAuth Security Topics'
> document
> > following the positive call for adoption at the last IETF
> > meeting in Seoul.
> >
> > Here is the document:
> >
> https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
> 
> <https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00>
> >
> > The intention with this document is to have a place to collect
> > discussions and conclusions around OAuth 2.0 security and to
> reference
> > the actual solution specifications.
> >
> > Please let us know by Feb 16th whether you accept / object
> to the
> > adoption of this document as a starting point for work in
> the OAuth
> > working group.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> _______
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] Downloading and uploading files by using OAuth in C# language on the Dropbox Platform without creating a new app on the Dropbox Platform to get applicationkey and secretkey?

[Jim Manico]

Riyadh,

You best off reading the Dropbox OAuth guide and asking Dropbox support with 
your questions. Each provider does OAuth a little bit differently.

https://www.dropbox.com/developers/reference/oauth-guide

Respectfully,
--
Jim Manico
@Manicode

> On Dec 22, 2016, at 1:49 AM, Riyadh Biyram <riyadh.biy...@gmail.com> wrote:
> 
> 
> Hello,
> 
> I use currently the OAuth technique and I have a question and I hope, you can 
> help me?
> 
> I would like to know how can I use OAuth 2.0 (within C# WPF application or 
> any langauge to achieve the request) to download and upload files from 
> Dropbox. It appears that the OAuth 2.0 works by forwarding you to a Dropbox 
> Platform and getting you confirm details for example that is means 
> registering the application with external providers(Dropbox Platform API) to 
> get the application key and secret key.
> (creating a new application on the Dropbox platform 
> to get applicationkey and secret key
>  https://www.dropbox.com/developers/apps/create).
> 
> How can I use it without application key and secret key direct to connect and 
> maybe get the application key with secret key in background without showing 
> anything to the user of the application for example like "Screenpresso" 
> software with this software you don't need to get applciation key or secret 
> key only you sign in by the email and password to grant access the features.
>  
> If there are other extra techniques, please write them to my email.
> 
> Thanks in advance.
> Best regards,
> 
> Riyadh Biyram
> 
>   
> Riyadh Biyram
> Software Engineer & Software Developer
> m:  +49 (0) 1577 858 6688   |e:rb50...@gmail.com Skype :riyadh.biyram 
> ___
> 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 Tokens and URI's

[Jim Manico]

... One more note. You mentioned in this section...

   o  Use form post mode instead of redirect for authorization response

.. This might be worth expanding on./Use form post and keep data OUT OF
THE ACTION/ (which is essentially the same as a GET). Safe transport of
tokens includes well configured HTTPS, POST and other verbs, and data
being the body of the request, not in the action of a form. Fair?

(And sorry, I missed this one the first time around)

Aloha, Jim

On 12/9/16 8:54 PM, Jim Manico wrote:
> Torsten,
>
> The
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1
> guide you are working on is a special kind of magic. Thank you for
> taking the time to write this very important document.
>
> When it comes to 2.2.1, I see your great suggestion to prevent
> referrer leakage. These defenses are very important, and I appreciate
> how clearly you laid these out.
>
> But I think they skip the really core problem that web security
> solutions must embrace - which I believe to be, /do not put sensitive
> data in URL/GET parameters/. This goes all the way back to RFC 2616
> #9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of
> taking an action other than retrieval" which I feel implies "should
> not do anything dangerous" including transport sensitive data.
>
> OAuth 2 goes pretty wild - all the way - with putting very sensitive
> tokens in URIs/URLs and I have seen some solutions that break the
> "standard" and POST/PUT/PATCH when they can, keeping tokens out of
> POST actions, URL's and similar.  Is this worth discussing?
>
> Thank you again for this very important and well written document.
>
> Aloha from Hawaii,
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

[OAUTH-WG] OAuth Tokens and URI's

[Jim Manico]

Torsten,

The
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1
guide you are working on is a special kind of magic. Thank you for
taking the time to write this very important document.

When it comes to 2.2.1, I see your great suggestion to prevent referrer
leakage. These defenses are very important, and I appreciate how clearly
you laid these out.

But I think they skip the really core problem that web security
solutions must embrace - which I believe to be, /do not put sensitive
data in URL/GET parameters/. This goes all the way back to RFC 2616
#9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval" which I feel implies "should not
do anything dangerous" including transport sensitive data.

OAuth 2 goes pretty wild - all the way - with putting very sensitive
tokens in URIs/URLs and I have seen some solutions that break the
"standard" and POST/PUT/PATCH when they can, keeping tokens out of POST
actions, URL's and similar.  Is this worth discussing?

Thank you again for this very important and well written document.

Aloha from Hawaii,

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Jim Manico]

Dude. You're freaking awesome. Thanks for this insight.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
> 
> +1 on providing guidance.
> 
> 
>> On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell 
>> <bcampb...@pingidentity.com> wrote:
>> Yes, I believe you are correct. Client certificates are provided in the 
>> handshake (initial or renegotiated) at the request of the server. If the 
>> server asks and the client doesn't provide a cert, it's up to the server 
>> whether to continue or about the handshake. 
>> 
>> There seem to be a number of different ways of trying to deal with this (not 
>> strictly for this OAuth case but similar situations).
>> 
>> The AS could always request client certs but allow connections to proceed 
>> regardless. Then check for certs for appropriate clients while processing 
>> token requests.  I guess there's a little overhead in the handshake with 
>> this for all the connections that won't present a cert. But not a ton. The 
>> main drawback is that some/many browsers have UI that will prompt users to 
>> choose a cert even when they don't have any. And the user experience can be 
>> very bad or confusing as a result.
>> 
>> The token endpoint could be on a different host or port which always 
>> requests client certs. Still allow connections to proceed regardless and 
>> check the client credentials at the OAuth layer. Pretty similar to the above 
>> but avoids the usability issues with end users because it's only at the 
>> token endpoint. 
>> 
>> Trying renegotiation after the application sees that it's a token request or 
>> that it's a token request from a client id that's configured for mutual TLS 
>> is another approach. In my own limited experience with this kind of thing, 
>> however, this approach can be kind of flaky. And your point about the 
>> initial data not being trustworthy is legitimate. I'm not sure if it really 
>> matters in this case. I don't know. And signaling to resubmit is another 
>> issue all together. 
>> 
>> There are probably other approaches too but those are the things I've seen 
>> or can imagine. In all (or nearly all) the deployments of our stuff that I 
>> know about that deal with mutual TLS, some variation of the second option is 
>> used. 
>> 
>> All this seem like implementation/deployment details though and I'm hesitant 
>> to try and define how to do it in this doc. Maybe providing some guidance. 
>> I'm not exactly sure how to do that though.  
>> 
>> 
>> 
>>> On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>>> Torstens questions triggers another question from me. 
>>> 
>>> If we have an AS that can handle both certificate client auth and client 
>>> secret, how does the AS know that it should ask for client certificate on 
>>> the TLS layer.
>>> 
>>> It was a while since I last read the TLS specification and it might have 
>>> changed but if i remember correctly client certificates are provided in 
>>> initial handshake or in re-negotiate and it is only provided on request by 
>>> the server.
>>> 
>>> If this is still true the AS would need to first get the token request, see 
>>> that this is a client that authenticates with certificate and request a TLS 
>>> re-negotiate to get the certificate authentication and a re-submission of 
>>> the token request since we cannot trust the data first submitted.
>>> 
>>> Are I missing something obvious, or is this something that needs to be 
>>> defined?
>>> 
>>> //Samuel
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>>>> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jric...@mit.edu> wrote:
>>>> Right — this is a fine way to put it. RFC7591 defines a client model where 
>>>> RFC6749 didn’t. Ideally all that metadata would’ve been in the original 
>>>> spec, but it’s not. It doesn’t matter whether the client was registered 
>>>> dynamically or statically, it just matters that the AS knows what to 
>>>> expect from a given client.
>>>> 
>>>>  — Justin
>>>> 
>>>>> On Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampb...@pingidentity.com> 
>>>>> wrote:
>>>>> 
>>>>> Yes, the intend is that the authentication method is determined by client 
>>>>> policy regar

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Jim Manico]

You could also sign the client_id with your private cert and send it
like normal OAuth requests...

But I like the idea of mapping the client_id server-side to the cert as
well.

Now we're talking real security. Bearer tokens are so Q1-2016. :)

Aloha, Jim

On 11/3/16 1:11 PM, Sergey Beryozkin wrote:
> Hi
>
> In our implementation we support the following scenario:
> - the client registers its public certificate during the client
> registration
>
> - next, mutual/two-way TLS is used, so AccessTokenService tries to
> figure out the client_id. At the moment it assumes the client_id is
> (Java) X509Certificate.getSubjectX500Principal().getName().
>
> Next it retrieves a client with this name and compares the TLS
> client/peer certificate against the pre-registered one.
>
> I think it may be interesting to explore further if client_id can
> become optional based on what Samuel said.
>
> For example, indeed I can see how I can update our code to have a
> mapping between some of client certificate's properties and a client
> id stored within a Client registration.
>
> The question is how to find a given Client registration effectively
> given only a certificate, without an optional client_id. One would
> need to have a map between these client certificate attribute and
> client_id or Clients.
>
> Cheers, Sergey
>
>
>
> On 03/11/16 16:48, Samuel Erdtman wrote:
>> I can see your point, maybe the client_id will not be in the
>> certificate.
>> If I had an AS I would select to trust one or several CAs and then
>> create certificate mappings between certificate serial number (or some
>> other unique attribute in the certificate) and client_id. If I were to
>> bind a specific certificate to a client_id I lose the flexibility of the
>> PKI (maybe what you want).
>>
>> I think multiple certificates might not be a uncommon situation
>> especially if you call ASs from different organizations because they
>> will trust different CAs.
>>
>> //Samuel
>>
>>
>> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <jric...@mit.edu
>> <mailto:jric...@mit.edu>> wrote:
>>
>> Jim,
>>
>> In those circumstances, are the clients generally calling multiple
>> different services? Or just one? For those that call multiple
>> services, are they using multiple (different) client certificates?
>>
>> I’m not saying the client would issue its own cert in all cases —
>> much more common is what I’ve seen, with clients being assigned a
>> certificate from a trusted CA, and then services that the client
>> talks to being told to trust that CA and also assign the CN/DN of
>> the cert a set of privileges. What I *haven’t* seen is a client
>> being issued multiple certificates to talk to multiple systems. That
>> latter case is common enough in the OAuth world that I wouldn’t want
>> us to paint ourselves in a corner.
>>
>>  — Justin
>>
>>> On Nov 3, 2016, at 10:31 AM, Jim Manico <j...@manicode.com
>>> <mailto:j...@manicode.com>> wrote:
>>>
>>> Thanks Justin. I use several security intel services and they all
>>> have different cert delivery mechanisms for mutual TLS. It's
>>> •rare• for services to let clients choose certs, they are usually
>>> assigned to users by each service from my experience.
>>>
>>> Aloha,
>>> --
>>> Jim Manico
>>> @Manicode
>>> Secure Coding Education
>>> +1 (808) 652-3805 <tel:%2B1%20%28808%29%20652-3805>
>>>
>>> On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu
>>> <mailto:jric...@mit.edu>> wrote:
>>>
>>>> Yes, I elided the certificate issuance process. The point remains
>>>> the same: you're not going to be submitting a CSR to the same
>>>> party you're getting your client_id from, usually. If the draft
>>>> assumes that, then it's incredibly limiting.
>>>>
>>>>
>>>> Do people really use separate TLS client certs for separate
>>>> connections in the wild? I've personally never seen that. What
>>>> I've seen is that a piece of software gets its certificate that
>>>> it uses to make whatever connections it needs to make.
>>>>
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>>>>> Just to be clear, the relationship should more like...
&

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Jim Manico]

> In those circumstances, are the clients generally calling multiple
different services? Or just one? For those that call multiple services,
are they using multiple (different) client certificates?

Ah, good point. I hear you now.  I personally like the idea of "one cert
per service" so I can selectively manage each access separately, but I
understand where you are coming from and it makes sense.

Thanks for taking the time to respectfully explain your perspective and
provide me with a little education. :)

ALOHA,

Jim Manico


On 11/3/16 12:32 PM, Justin Richer wrote:
> Jim,
>
> In those circumstances, are the clients generally calling multiple
> different services? Or just one? For those that call multiple
> services, are they using multiple (different) client certificates?
>
> I’m not saying the client would issue its own cert in all cases — much
> more common is what I’ve seen, with clients being assigned a
> certificate from a trusted CA, and then services that the client talks
> to being told to trust that CA and also assign the CN/DN of the cert a
> set of privileges. What I *haven’t* seen is a client being issued
> multiple certificates to talk to multiple systems. That latter case is
> common enough in the OAuth world that I wouldn’t want us to paint
> ourselves in a corner.
>
>  — Justin
>
>> On Nov 3, 2016, at 10:31 AM, Jim Manico <j...@manicode.com
>> <mailto:j...@manicode.com>> wrote:
>>
>> Thanks Justin. I use several security intel services and they all
>> have different cert delivery mechanisms for mutual TLS. It's •rare•
>> for services to let clients choose certs, they are usually assigned
>> to users by each service from my experience.
>>
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>> Secure Coding Education
>> +1 (808) 652-3805
>>
>> On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu
>> <mailto:jric...@mit.edu>> wrote:
>>
>>> Yes, I elided the certificate issuance process. The point remains
>>> the same: you're not going to be submitting a CSR to the same party
>>> you're getting your client_id from, usually. If the draft assumes
>>> that, then it's incredibly limiting.
>>>
>>>
>>> Do people really use separate TLS client certs for separate
>>> connections in the wild? I've personally never seen that. What I've
>>> seen is that a piece of software gets its certificate that it uses
>>> to make whatever connections it needs to make.
>>>
>>>
>>>  -- Justin
>>>
>>>
>>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>>>> Just to be clear, the relationship should more like...
>>>>
>>>> AS issues public key to clients, or client sends public key to AS.
>>>> The authorities job is NOT to give the client the public key, but
>>>> to sign the public key for authenticity. It's bad practice to
>>>> accept the full cert (pub key+signature) from an authority. If an
>>>> authority is creating your public key, they are also creating your
>>>> private key bad.
>>>>
>>>> > The client will use the same cert across multiple connections,
>>>> possibly multiple AS's, but the same isn't true of the client_id. 
>>>>
>>>> This seems like a bad idea. I suggest a separate key/signature for
>>>> each service.
>>>> --
>>>> Jim Manico
>>>> @Manicode
>>>> Secure Coding Education
>>>> +1 (808) 652-3805
>>>>
>>>> On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu
>>>> <mailto:jric...@mit.edu>> wrote:
>>>>
>>>>> I agree that the client_id is unlikely to be found inside the
>>>>> certificate itself. The client_id is issued by the authorization
>>>>> server for the client to use at that single AS. The certificate is
>>>>> issued by the CA for the client to use on any connection. The AS
>>>>> and CA are not likely to be the same system in most deployments.
>>>>> The client will use the same cert across multiple connections,
>>>>> possibly multiple AS's, but the same isn't true of the client_id.
>>>>>
>>>>> Additionally, I think we want to allow for a binding of a
>>>>> self-signed certificate using dynamic registration, much the way
>>>>> that we already allow binding of a client-generated JWK today.
>>>>>
>>>>> I do think that more examples and guidance are warranted, though,
>>>

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Jim Manico]

Thanks Justin. I use several security intel services and they all have 
different cert delivery mechanisms for mutual TLS. It's •rare• for services to 
let clients choose certs, they are usually assigned to users by each service 
from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu> wrote:
> 
> Yes, I elided the certificate issuance process. The point remains the same: 
> you're not going to be submitting a CSR to the same party you're getting your 
> client_id from, usually. If the draft assumes that, then it's incredibly 
> limiting.
> 
> 
> Do people really use separate TLS client certs for separate connections in 
> the wild? I've personally never seen that. What I've seen is that a piece of 
> software gets its certificate that it uses to make whatever connections it 
> needs to make.
> 
> 
>  -- Justin
> 
>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>> Just to be clear, the relationship should more like...
>> 
>> AS issues public key to clients, or client sends public key to AS. The 
>> authorities job is NOT to give the client the public key, but to sign the 
>> public key for authenticity. It's bad practice to accept the full cert (pub 
>> key+signature) from an authority. If an authority is creating your public 
>> key, they are also creating your private key bad.
>> 
>> > The client will use the same cert across multiple connections, possibly 
>> > multiple AS's, but the same isn't true of the client_id. 
>> 
>> This seems like a bad idea. I suggest a separate key/signature for each 
>> service.
>> --
>> Jim Manico
>> @Manicode
>> Secure Coding Education
>> +1 (808) 652-3805
>> 
>> On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu> wrote:
>> 
>>> I agree that the client_id is unlikely to be found inside the certificate 
>>> itself. The client_id is issued by the authorization server for the client 
>>> to use at that single AS. The certificate is issued by the CA for the 
>>> client to use on any connection. The AS and CA are not likely to be the 
>>> same system in most deployments. The client will use the same cert across 
>>> multiple connections, possibly multiple AS's, but the same isn't true of 
>>> the client_id. 
>>> Additionally, I think we want to allow for a binding of a self-signed 
>>> certificate using dynamic registration, much the way that we already allow 
>>> binding of a client-generated JWK today. 
>>> I do think that more examples and guidance are warranted, though, to help 
>>> AS developers.
>>> 
>>>  -- Justin
>>> 
>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>>> 
>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>>>>> 
>>>>> I agree it is written so that the connection to the certificate is 
>>>>> implicitly required but I think it would be better if it was explicit 
>>>>> written since the lack of a connection would result in a potential 
>>>>> security hole.
>>>> 
>>>> That's fair. I agree it can be made more explicit and that it be good to 
>>>> do so. 
>>>> 
>>>>  
>>>>> When it comes to the client_id I think subject common name or maybe 
>>>>> subject serial numbers will be the common location, and I think an 
>>>>> example would be valuable.
>>>>>  
>>>> 
>>>> In my experience and the way we built support for mutual TLS OAuth client 
>>>> auth the client_id value does not appear in the certificate anywhere. I'm 
>>>> not saying it can't happen but don't think it's particularly common. 
>>>> 
>>>> I can look at adding some examples, if there's some consensus that they'd 
>>>> be useful and this document moves forward. 
>>>> 
>>>>  
>>>>> 
>>>>> I´m not saying it is a bad Idea just that I would prefer if it was not a 
>>>>> MUST. 
>>>>> With very limited addition of code it is just as easy to get the 
>>>>> certificate attribute for client id as it is to get it from the HTTP 
>>>>> request data (at least in java). I also think that with the requirement 
>>>>> to match the incoming certificate in some way one has to read out the 
>>>>> certificate that was used to establish the connection to do some kind of 
>>>>> matching.
>>>>> 
>>>> 
>>>> Getting data out of the certificate isn't a concern. I just believe that 
>>>> the constancy of having the client id parameter is worth the potential 
>>>> small amount duplicate data in some cases. It's just a -00 draft though 
>>>> and if the WG wants to proceed with this document, we seek further input 
>>>> and work towards some consensus. 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> 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] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Jim Manico]

Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The 
authorities job is NOT to give the client the public key, but to sign the 
public key for authenticity. It's bad practice to accept the full cert (pub 
key+signature) from an authority. If an authority is creating your public key, 
they are also creating your private key bad.

> The client will use the same cert across multiple connections, possibly 
> multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu> wrote:
> 
> I agree that the client_id is unlikely to be found inside the certificate 
> itself. The client_id is issued by the authorization server for the client to 
> use at that single AS. The certificate is issued by the CA for the client to 
> use on any connection. The AS and CA are not likely to be the same system in 
> most deployments. The client will use the same cert across multiple 
> connections, possibly multiple AS's, but the same isn't true of the 
> client_id. 
> Additionally, I think we want to allow for a binding of a self-signed 
> certificate using dynamic registration, much the way that we already allow 
> binding of a client-generated JWK today. 
> I do think that more examples and guidance are warranted, though, to help AS 
> developers.
> 
>  -- Justin
> 
>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>> 
>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote:
>>> 
>>> I agree it is written so that the connection to the certificate is 
>>> implicitly required but I think it would be better if it was explicit 
>>> written since the lack of a connection would result in a potential security 
>>> hole.
>> 
>> That's fair. I agree it can be made more explicit and that it be good to do 
>> so. 
>> 
>>  
>>> When it comes to the client_id I think subject common name or maybe subject 
>>> serial numbers will be the common location, and I think an example would be 
>>> valuable.
>>>  
>> 
>> In my experience and the way we built support for mutual TLS OAuth client 
>> auth the client_id value does not appear in the certificate anywhere. I'm 
>> not saying it can't happen but don't think it's particularly common. 
>> 
>> I can look at adding some examples, if there's some consensus that they'd be 
>> useful and this document moves forward. 
>> 
>>  
>>> 
>>> I´m not saying it is a bad Idea just that I would prefer if it was not a 
>>> MUST. 
>>> With very limited addition of code it is just as easy to get the 
>>> certificate attribute for client id as it is to get it from the HTTP 
>>> request data (at least in java). I also think that with the requirement to 
>>> match the incoming certificate in some way one has to read out the 
>>> certificate that was used to establish the connection to do some kind of 
>>> matching.
>>> 
>> 
>> Getting data out of the certificate isn't a concern. I just believe that the 
>> constancy of having the client id parameter is worth the potential small 
>> amount duplicate data in some cases. It's just a -00 draft though and if the 
>> WG wants to proceed with this document, we seek further input and work 
>> towards some consensus. 
>> 
>> 
>> 
>> ___
>> 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] JWT: Algorithm choice as an attack vector

[Jim Manico]

> A good app contract will specify which algs and header parameters are
accepted, and discard all JWTs that don't match these rules, before
passing the JWTs for validation to the library.

While this is ideal it's not always practical for authorization servers
that need to support a wide array of algs and header parameters.

This is also why - in addition to a good app contract - these token
should be proof tokens at multiple layers - including mutual TLS.

Aloha, Jim


On 10/5/16 7:11 PM, Vladimir Dzhuvinov wrote:
> Hi Maciej,
>
> Apps must not accept arbitrary JWTs, neither let the JWT header alone
> drive the JWT validation process.
>
> A good app contract will specify which algs and header parameters are
> accepted, and discard all JWTs that don't match these rules, before
> passing the JWTs for validation to the library.
>
>
> On 03/10/16 18:46, Maciej Kwidzinski wrote:
>> Hi,
>>
>> Tim McLean describes an attack vector on JWT-protected services in his
>> blog post: 
>> https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
>>
>> The culprit is relying on the algorithm in the JWT header. The
>> workaround/recommendation is to ignore the algorithm from the header
>> and use a predefined one.
>>
>> The current RFC 7519 does not address this vulnerability.
>> Will this problem be addressed in the standard?
>>
>> Best regards,
>> Maciej Kwidziński
>>
>> ___
>> 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

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] best practices for implicit grant / token storage

[Jim Manico]

> "keep away from implicit grants and do not store bearer tokens in the
browser" - that would be practically impossible for the envs that I was
writing about and "best practices"  that could not be enforced aren't
worth much. I can formulate it in stronger terms: if OAuth wouldn't
allow a JS client running in a browser its usability will be very low.

Are you sure you're not talking about OIDC or JWT's? The piece of advice
above is regarding using OAuth for delegation per the core spec. Advice
for Federation (OIDC) and advice for session management (putting JTW's
in cookies) would be different that recommending how to use OAuth for
delegation securely.

Fair?

- Jim


On 9/8/16 2:54 PM, Oleg Gryb wrote:
> "keep away from implicit grants and do not store bearer tokens in the
> browser" - that would be practically impossible for the envs that I
> was writing about and "best practices"  that could not be enforced
> aren't worth much. I can formulate it in stronger terms: if OAuth
> wouldn't allow a JS client running in a browser its usability will be
> very low.
>
> What could and should be improved in implicit grants is removing
> secrets from URL (fragment). That could be done as I've shown in the
> previous discussions.
>
>
> --------
> *From:* Jim Manico <j...@manicode.com>
> *To:* John Bradley <ve7...@ve7jtb.com>
> *Cc:* Oleg Gryb <o...@gryb.info>; Adam Lewis
> <adam.le...@motorolasolutions.com>; OAuth WG <oauth@ietf.org>
> *Sent:* Thursday, September 8, 2016 3:51 PM
> *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
> token storage
>
> +1000 on a OAuth Security Best Practices document. I'd be happy to
> review or help some.
> I think right now the answer is: keep away from implicit grants
> and do not store bearer tokens in the browser. Instead, use the
> authorization code grant which only exposes bearer tokens
> intra-server.
> For /*web apps*/, I feel the only good place to store
> authentication, session or token information is in a HTTPOnly
> flagged cookie to keep JS away from sensitive information.
>
> Aloha, Jim
>
>
> On 9/8/16 12:38 PM, John Bradley wrote:
> It is an interesting discussion, indicating that perhaps a best
> practices document is in order.
>
> I have had several people ask me about SPA using OAuth recently.
>
> Until we get the W3C to finish fetch and extend it for token
> binding, we are going to have ongoing issues with bearer tokens in
> the browser and where to store them.
>
> I don’t know that there is a perfect solution for bearer tokens,
> but documenting the tradeoffs may be useful.
>
> John B.
>
>> On Sep 8, 2016, at 6:07 PM, Jim Manico <j...@manicode.com
>> <mailto:j...@manicode.com>> wrote:
>>
> +1 I think that's a very fair perspective.
> Putting sensitive data in LocalStorage is still a very bad idea.
> :) One XSS and gone. Maybe XSS is not a big deal in a native app,
> but it's death to Web apps.
> Aloha, Jim
>
> On 9/8/16 10:20 AM, Oleg Gryb wrote:
>> In SPA/REST env session ID is not very useful, so it's *an* auth
>> token or tokens (not necessary OAuth one) that are stored in a
>> cookie. It's used to get REST calls authenticated and yes, it
>> usually runs in a multi-domain envs (think about micro services
>> architecture). It makes me think that the value of HTTPOnly will
>> continue diminishing, while the value of good cross-domain
>> policies will increase. Just my opinion coming from my
>> experience. I don't have big (or small) data available to confirm
>> that.  
>>
>>
>> 
>> 
>> *From:* Jim Manico <j...@manicode.com> <mailto:j...@manicode.com>
>> *To:* Oleg Gryb <o...@gryb.info> <mailto:o...@gryb.info>;
>> Adam Lewis <adam.le...@motorolasolutions.com>
>> <mailto:adam.le...@motorolasolutions.com>
>> *Cc:* OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org>
>> *Sent:* Thursday, September 8, 2016 12:51 PM
>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
>> token storage
>>
>> > Since SPA is a new normal now, it becomes extremely
>> difficult to enforce HTTPOnly flag, because JS needs access
>> to secrets including those stored in cookies.
>>

Re: [OAUTH-WG] best practices for implicit grant / token storage

[Jim Manico]

+1000 on a OAuth Security Best Practices document. I'd be happy to
review or help some.

I think right now the answer is: keep away from implicit grants and do
not store bearer tokens in the browser. Instead, use the authorization
code grant which only exposes bearer tokens intra-server.

For /*web apps*/, I feel the only good place to store authentication,
session or token information is in a HTTPOnly flagged cookie to keep JS
away from sensitive information.

Aloha, Jim


On 9/8/16 12:38 PM, John Bradley wrote:
> It is an interesting discussion, indicating that perhaps a best
> practices document is in order.
>
> I have had several people ask me about SPA using OAuth recently.
>
> Until we get the W3C to finish fetch and extend it for token binding,
> we are going to have ongoing issues with bearer tokens in the browser
> and where to store them.
>
> I don’t know that there is a perfect solution for bearer tokens, but
> documenting the tradeoffs may be useful.
>
> John B.
>
>> On Sep 8, 2016, at 6:07 PM, Jim Manico <j...@manicode.com
>> <mailto:j...@manicode.com>> wrote:
>>
>> +1 I think that's a very fair perspective.
>>
>> Putting sensitive data in LocalStorage is still a very bad idea. :)
>> One XSS and gone. Maybe XSS is not a big deal in a native app, but
>> it's death to Web apps.
>>
>> Aloha, Jim
>>
>>
>> On 9/8/16 10:20 AM, Oleg Gryb wrote:
>>> In SPA/REST env session ID is not very useful, so it's *an* auth
>>> token or tokens (not necessary OAuth one) that are stored in a
>>> cookie. It's used to get REST calls authenticated and yes, it
>>> usually runs in a multi-domain envs (think about micro services
>>> architecture). It makes me think that the value of HTTPOnly will
>>> continue diminishing, while the value of good cross-domain policies
>>> will increase. Just my opinion coming from my experience. I don't
>>> have big (or small) data available to confirm that.  
>>>
>>>
>>> 
>>> *From:* Jim Manico <j...@manicode.com>
>>> *To:* Oleg Gryb <o...@gryb.info>; Adam Lewis
>>> <adam.le...@motorolasolutions.com>
>>> *Cc:* OAuth WG <oauth@ietf.org>
>>> *Sent:* Thursday, September 8, 2016 12:51 PM
>>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
>>> token storage
>>>
>>> > Since SPA is a new normal now, it becomes extremely difficult
>>> to enforce HTTPOnly flag, because JS needs access to secrets
>>> including those stored in cookies.
>>> In a browser environment, this is only true when you need to
>>> make cross domain requests or are using cookie data for
>>> something other than session state.
>>> If your current page origin and the page you are requesting are
>>> the same, then your cookies can be HTTPOnly without impacting
>>> functionality. If you need additional cookies for other things
>>> that need to be accessed via JS, use a separate cookie.
>>> So sure, there are a few workflows in OAuth where you need to
>>> access "cookie data" from JS and HTTPOnly is not viable. But
>>> there are a few where it is viable. I don't think it's as simple
>>> as "we need to talk to cookie data via JS all the time.".
>>> Aloha, Jim
>>>     On 9/8/16 8:15 AM, Oleg Gryb wrote:
>>>> Jim,
>>>>
>>>> It's outdated a bit. Since SPA is a new normal now, it becomes
>>>> extremely difficult to enforce HTTPOnly flag, because JS needs
>>>> access to secrets including those stored in cookies. 5-10 years
>>>> ago I would always enforce HTTPOnly and now - I can't.
>>>>
>>>> Thanks,
>>>> Oleg.
>>>>
>>>> 
>>>> 
>>>> *From:* Jim Manico <j...@manicode.com> <mailto:j...@manicode.com>
>>>> *To:* Adam Lewis <adam.le...@motorolasolutions.com>
>>>> <mailto:adam.le...@motorolasolutions.com>
>>>> *Cc:* OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org>
>>>> *Sent:* Thursday, September 8, 2016 10:45 AM
>>>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant
>>>> / token storage
>>>>
>>>> In the web world,

Re: [OAUTH-WG] best practices for implicit grant / token storage

[Jim Manico]

+1 I think that's a very fair perspective.

Putting sensitive data in LocalStorage is still a very bad idea. :) One
XSS and gone. Maybe XSS is not a big deal in a native app, but it's
death to Web apps.

Aloha, Jim


On 9/8/16 10:20 AM, Oleg Gryb wrote:
> In SPA/REST env session ID is not very useful, so it's *an* auth token
> or tokens (not necessary OAuth one) that are stored in a cookie. It's
> used to get REST calls authenticated and yes, it usually runs in a
> multi-domain envs (think about micro services architecture). It makes
> me think that the value of HTTPOnly will continue diminishing, while
> the value of good cross-domain policies will increase. Just my opinion
> coming from my experience. I don't have big (or small) data available
> to confirm that.  
>
>
> --------
> *From:* Jim Manico <j...@manicode.com>
> *To:* Oleg Gryb <o...@gryb.info>; Adam Lewis
> <adam.le...@motorolasolutions.com>
> *Cc:* OAuth WG <oauth@ietf.org>
> *Sent:* Thursday, September 8, 2016 12:51 PM
> *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
> token storage
>
> > Since SPA is a new normal now, it becomes extremely difficult to
> enforce HTTPOnly flag, because JS needs access to secrets
> including those stored in cookies.
> In a browser environment, this is only true when you need to make
> cross domain requests or are using cookie data for something other
> than session state.
> If your current page origin and the page you are requesting are
> the same, then your cookies can be HTTPOnly without impacting
> functionality. If you need additional cookies for other things
> that need to be accessed via JS, use a separate cookie.
> So sure, there are a few workflows in OAuth where you need to
> access "cookie data" from JS and HTTPOnly is not viable. But there
> are a few where it is viable. I don't think it's as simple as "we
> need to talk to cookie data via JS all the time.".
> Aloha, Jim
> On 9/8/16 8:15 AM, Oleg Gryb wrote:
>> Jim,
>>
>> It's outdated a bit. Since SPA is a new normal now, it becomes
>> extremely difficult to enforce HTTPOnly flag, because JS needs
>> access to secrets including those stored in cookies. 5-10 years
>> ago I would always enforce HTTPOnly and now - I can't.
>>
>> Thanks,
>> Oleg.
>>
>> 
>> 
>> *From:* Jim Manico <j...@manicode.com> <mailto:j...@manicode.com>
>> *To:* Adam Lewis <adam.le...@motorolasolutions.com>
>> <mailto:adam.le...@motorolasolutions.com>
>> *Cc:* OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org>
>> *Sent:* Thursday, September 8, 2016 10:45 AM
>> *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
>> token storage
>>
>> In the web world, cookies for session identifiers are much
>> safer - since we can use HTTPOnly cookies to protect them
>> from theft via XSS. The same mechanism is not possible for
>> localStorage. Overall, security folk say •keep sensitive data
>> out of localStorage• since one XSS and it's stolen. There is
>> also a huge body of work underway to make secure cookies even
>> more so.
>>
>> I'm not sure how this translates to native apps.
>>
>> --
>> Jim Manico
>> @Manicode
>>
>> On Sep 8, 2016, at 3:02 AM, Adam Lewis
>> <adam.le...@motorolasolutions.com
>> <mailto:adam.le...@motorolasolutions.com>> wrote:
>>
>>> Hi,
>>>
>>> The WG is currently putting together best practices for
>>> native apps.  I would like to better understand the best
>>> practices around ua-based-apps, especially as it relates to
>>> token storage.  I've read various blog posts about the
>>> preference between storing tokens in cookies vs.  Web
>>> Storage (localStorage/sessionStorage).  The current set of
>>> specs are rather silent on the matter, as it is more of an
>>> implementation issue (but that is where most mistakes are made).
>>>
>>> What is the WG's guidance on this?
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org <

Re: [OAUTH-WG] best practices for implicit grant / token storage

[Jim Manico]

In the web world, cookies for session identifiers are much safer - since we can 
use HTTPOnly cookies to protect them from theft via XSS. The same mechanism is 
not possible for localStorage. Overall, security folk say •keep sensitive data 
out of localStorage• since one XSS and it's stolen. There is also a huge body 
of work underway to make secure cookies even more so.

I'm not sure how this translates to native apps.

--
Jim Manico
@Manicode

> On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.le...@motorolasolutions.com> 
> wrote:
> 
> Hi,
> 
> The WG is currently putting together best practices for native apps.  I would 
> like to better understand the best practices around ua-based-apps, especially 
> as it relates to token storage.  I've read various blog posts about the 
> preference between storing tokens in cookies vs.  Web Storage 
> (localStorage/sessionStorage).  The current set of specs are rather silent on 
> the matter, as it is more of an implementation issue (but that is where most 
> mistakes are made).
> 
> What is the WG's guidance on this?
> ___
> 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] [Technical Errata Reported] RFC6749 (4749)

[Jim Manico]

Thank you Justin, comments inline.

> These are client secrets, not user passwords, so they’re supposed to be high 
> entropy and not human-memorable (or human-typable really). 

This still sounds like sensitive data, and I don't understand the relevance of 
"human memorable". If time allows can you tell me more?

> Also, this needs to be used over TLS. 

Sure, but the problems of HTTP Basic are well established and go beyond TLS (no 
timeout, included in each request, cached by the browser for that window 
session, etc).

> The connection requires TLS anyway because the tokens returned (or the token 
> keys in the OAuth PoP case) also need to be protected, regardless of how you 
> hash the client’s secret. With that in mind, Digest doesn’t buy you much.

So this looks like a way to transport the client id and secret. Wouldn't some 
form of "strong authentication" like mutual TLS or similar be a better default 
standard? The OAuth 2 threat model makes this exact recommendation.

Respectfully,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jul 28, 2016, at 4:25 PM, Justin Richer <jric...@mit.edu> wrote:
> 
> These are client secrets, not user passwords, so they’re supposed to be high 
> entropy and not human-memorable (or human-typable really). Also, this needs 
> to be used over TLS. The connection requires TLS anyway because the tokens 
> returned (or the token keys in the OAuth PoP case) also need to be protected, 
> regardless of how you hash the client’s secret. With that in mind, Digest 
> doesn’t buy you much.
> 
> — Justin
> 
>> On Jul 26, 2016, at 8:08 PM, Jim Manico <j...@manicode.com> wrote:
>> 
>> Please forgive me if this comment is out of order or inappropriate in any 
>> way...
>> 
>> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
>> security properties at multiple levels; shouldn't we at least move to HTTP 
>> Digest if not something stronger?
>> 
>> Regards.
>> --
>> Jim Manico
>> @Manicode
>> 
>>> On Jul 26, 2016, at 4:48 PM, RFC Errata System <rfc-edi...@rfc-editor.org> 
>>> wrote:
>>> 
>>> The following errata report has been submitted for RFC6749,
>>> "The OAuth 2.0 Authorization Framework".
>>> 
>>> --
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Phil Hunt <phil.h...@oracle.com>
>>> 
>>> Section: 2.3.1
>>> 
>>> Original Text
>>> -
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password.  The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>> 
>>> Corrected Text
>>> --
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password. The url encoded values are then encoded as defined in
>>> [RFC2617]. The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>> 
>>> Notes
>>> -
>>> It was not clear to some implementers that the intention is a 2-step 
>>> encoding. First for special characters and second the 2617 base 64 
>>> encoding.  Implementers thought 6749 was in conflict with 2617.
>>> 
>>> To avoid inter-op issues, a new clarifying sentence is proposed.
>>> "The url encoded values are then encoded as defined in [RFC2617]."
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Jim Manico]

Please forgive me if this comment is out of order or inappropriate in any way...

...but why is HTTP Basic even being discussed in 2016? It has horrific security 
properties at multiple levels; shouldn't we at least move to HTTP Digest if not 
something stronger?

Regards.
--
Jim Manico
@Manicode

> On Jul 26, 2016, at 4:48 PM, RFC Errata System <rfc-edi...@rfc-editor.org> 
> wrote:
> 
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
> 
> --
> Type: Technical
> Reported by: Phil Hunt <phil.h...@oracle.com>
> 
> Section: 2.3.1
> 
> Original Text
> -
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password.  The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
> 
> Corrected Text
> --
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password. The url encoded values are then encoded as defined in
> [RFC2617]. The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
> 
> Notes
> -
> It was not clear to some implementers that the intention is a 2-step 
> encoding. First for special characters and second the 2617 base 64 encoding.  
> Implementers thought 6749 was in conflict with 2617.
> 
> To avoid inter-op issues, a new clarifying sentence is proposed.
> "The url encoded values are then encoded as defined in [RFC2617]."
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] Security concern for URI fragment as Implicit grant

[Jim Manico]

HTTP POST requests are also a lot more difficult to cache server side compared 
to URI's which are easier to cache. I'm likely not explaining this well, but I 
believe it's a webscale concern.

--
Jim Manico
@Manicode

> On Jul 1, 2016, at 11:01 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote:
> 
> AFAIR, they were talking about cost of this additional POST on the server 
> side, which was not good for high volume traffic (millions requests per day). 
> I'll try to dig it out to find more details. 
> 
> 
> From: Liyu Yi <liy...@gmail.com>
> To: John Bradley <ve7...@ve7jtb.com> 
> Cc: Oleg Gryb <o...@gryb.info>; Jim Manico <j...@manicode.com>; 
> "oauth@ietf.org" <oauth@ietf.org>
> Sent: Friday, July 1, 2016 1:42 PM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> BTW, I do not see any significant performance concerns for post. Parsing and 
> executing the Javascript logic for post operation will be on the client side, 
> no extra server load is introduced.
> 
> Plus post will remove the size restriction of the URL length.
> 
> -- Liyu 
> 
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi <liy...@gmail.com> wrote:
> Thanks for the great comments and advices.
> 
> I think it is a good idea for the working group to revise the fragment part 
> in the spec, since there might be public available tools already implemented 
> this approach and people can end up with a solution with serious security 
> loopholes.
> 
> The re-append issue can be mitigate by a logic on Resource Server which 
> carefully re-writes/removes the fragment in any redirect, if the the redirect 
> can not be avoided.
> 
> -- Liyu
>  
> 
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim; might result in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
> 
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim”
> 
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry; might result in a 301
>(Moved Permanently) response containing the header field:
> 
>  Location: http://www.example.net/index.html
> 
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry;, preserving the original
>fragment identifier.
> 
> 
> This blog also explores the change.
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
> 
> 
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was  when 
>> originally specified" - thanks Jim. Looks like a good reason for vetting 
>> this flow out.
>> 
>> John,
>> Please provide more details/links about re-appending fragments. 
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico <j...@manicode.com>
>> To: Oleg Gryb <o...@gryb.info> 
>> Cc: "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <liy...@gmail.com>
>> Sent: Thursday, June 30, 2016 10:25 PM
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> Oleg! Hello! Great to see you pop up here with a similar concern.
>> 
>> John Bradley just answered this thread with the details I was looking for 
>> (thanks John, hat tip your way).
>> 
>> He also mentioned details about fragment leakage:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was when 
>> originally specified"
>> 
>> Again, I'm new here but I'm grateful for this conversation.
>> 
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>> 
>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote:
>>> 
>>&

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Jim Manico]

Oleg! Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"

Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

> On Jul 1, 2016, at 1:24 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote:
> 
> We've discussed access tokens in URI back in 2010 
> (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There 
> were two major objectives when I was saying that it's not secure:
> 
> 1. Fragment is not sent to a server by a browser. When I've asked if this is 
> true for every browser in the world, nobody was able to answer.
> 2. Replacing with POST would mean a significant performance impact in some 
> high volume implementations (I think it was Goole folks who were saying this, 
> but I don't remember now).
> 
> AFAIR, nobody was arguing about browsing history, so it's valid.
> 
> So, 6 years later we're at square one with this and I hope that this time the 
> community will be more successful with getting rid of secrets in URL.
> 
> BTW, Jim, if you can come up with other scenarios when fragments can leak, 
> please share. It'll probably help the community with solving this problem 
> faster than in 6 years.
> 
> Thanks,
> Oleg.
> 
> 
> From: Jim Manico <j...@manicode.com>
> To: Liyu Yi <liy...@gmail.com>; oauth@ietf.org 
> Sent: Wednesday, June 29, 2016 7:30 AM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> > Shouldn’t it be more secure if we change to use a post method for access 
> > token, similar to the SAML does?
> I say yes. But please note I'm very new at this and someone with more 
> experience will have more to say or correct my comments.
> Here are a few more details to consider.
> 1) OAuth is a framework and not a standard, per se. Different authorization 
> servers will have different implementations that are not necessarily 
> compatible with other service providers. So there is no standard to break, 
> per se.
> 2) Sensitive data in a URI is a bad idea. They leak all over the place even 
> over HTTPS. Even in fragments.
> 3) Break the "rules" and find a way to submit sensitive data like access 
> tokens, session information or any other (even short term) sensitive data in 
> a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and 
> other verbs - all over well configured HTTPS.
> 4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE 
> (with limited scopes/lifetimes) to provide message level confidentiality and 
> integrity.
> Aloha,
> Jim Manico
> Manicode Security
> https://www.manicode.com
> 
>> On 6/27/16 9:30 PM, Liyu Yi wrote:
>> While we are working on a project with OAuth2 implementation, one question 
>> arises from our engineers.
>> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it 
>> is specified that
>>   
>> (C)  Assuming the resource owner grants access, the authorization
>> server redirects the user-agent back to the client using the
>> redirection URI provided earlier.  The redirection URI includes
>> the access token in the URI fragment.
>>  
>> For my understanding, the browser keeps the URI fragment in the history, and 
>> this introduces unexpected exposure of the access token. A user without 
>> authorization for the resource can get the access token as long as he has 
>> the access to the browser. This can happen in a shared computer in library, 
>> or for an IT staff who works on other employee’s computer.
>>  
>> Shouldn’t it be more secure if we change to use a post method for access 
>> token, similar to the SAML does?
>> I feel there might be something I missed here. Any advices will be 
>> appreciated.
>> 
>> 
>> ___
>> 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] Security concern for URI fragment as Implicit grant

[Jim Manico]

> Shouldn’t it be more secure if we change to use a post method for
access token, similar to the SAML does?

I say yes. But please note I'm very new at this and someone with more
experience will have more to say or correct my comments.

Here are a few more details to consider.

1) OAuth is a framework and not a standard, per se. Different
authorization servers will have different implementations that are not
necessarily compatible with other service providers. So there is no
standard to break, per se.

2) Sensitive data in a URI is a bad idea. They leak all over the place
even over HTTPS. Even in fragments.

3) Break the "rules" and find a way to submit sensitive data like access
tokens, session information or any other (even short term) sensitive
data in a secure fashion. This includes POST, JSON data payloads over
PUT/PATCH and other verbs - all over well configured HTTPS.

4) If you really must submit sensitive data over GET , consider
JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level
confidentiality and integrity.

Aloha,

Jim Manico
Manicode Security
https://www.manicode.com


On 6/27/16 9:30 PM, Liyu Yi wrote:
>
> While we are working on a project with OAuth2 implementation, one
> question arises from our engineers.
>
> We noticed at
> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is
> specified that
>
>   
>
> (C)  Assuming the resource owner grants access, the authorization
>
> server redirects the user-agent back to the client using the
>
> redirection URI provided earlier.  The redirection URI includes
>
> the access token in the URI fragment.
>
>  
>
> For my understanding, the browser keeps the URI fragment in the
> history, and this introduces unexpected exposure of the access token.
> A user without authorization for the resource can get the access token
> as long as he has the access to the browser. This can happen in a
> shared computer in library, or for an IT staff who works on other
> employee’s computer.
>
>  
>
> Shouldn’t it be more secure if we change to use a post method for
> access token, similar to the SAML does?
>
> I feel there might be something I missed here. Any advices will be
> appreciated.
>
>
>
> ___
> 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] Multi-AS State Re-Use

[Jim Manico]

Well hey now.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
is one of the more popular resources on CSRF at OWASP.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) is
also pretty popular and points to a wide variety of resources on the topic.

If anyone sees any flaws in these or otherwise would like to help make
these better, please drop me a line. I serve on the OWASP board.

Aloha, Jim Manico



On 5/11/16 11:59 AM, Nat Sakimura wrote:
> Agreed. Also, pointing to OWASP guide or something for CSRF token may
> be useful.
> On Tue, May 10, 2016 at 11:37 Daniel Fett <f...@uni-trier.de
> <mailto:f...@uni-trier.de>> wrote:
>
> Regardless of what state actually is, the documentation (also the one
> for OIDC) should make clear that the same state should not be sent to
> two different AS, and that a state issued for AS #1 should be invalid
> for AS #2.
>
> Am 10.05.2016 um 09:31 schrieb Anthony Nadalin:
> > STATE can be anything, it does not have to be a NONCE so
> changing this
> > would cause issues at this time for existing deployments
> >
> >
> >
> > *From:*OAuth [mailto:oauth-boun...@ietf.org
> <mailto:oauth-boun...@ietf.org>] *On Behalf Of *Nat Sakimura
> > *Sent:* Monday, May 9, 2016 7:34 PM
> > *To:* Guido Schmitz <g.schm...@gtrs.de
> <mailto:g.schm...@gtrs.de>>; oauth@ietf.org <mailto:oauth@ietf.org>
> > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
> >
> >
> >
> > As far as I am aware of, state was meant to be nonce. Replay
> possibility
> > etc. were known. It is probably a bad documentation that every
> reviewers
> > missed because they were assuming it.
>
>
> --
> Informationssicherheit und Kryptografie
> Universität Trier - Tel. 0651 201 2847 - H436
>
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
> Nat Sakimura
> Chairman of the Board, OpenID Foundation
> Trustee, Kantara Initiative
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com

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

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[Jim Manico]

Phil,

There are four standard session ending controls.

1) Logout
2) Idle session timeout
3) Absolute timeout
4) Forced re-authentication

I think these are still important and tend to not get full attention from the 
OAuth/OIDC crowd. :) 

But the OAuth 2 standard in particular is a framework - not a standard - which 
can be implemented many ways, of course.

Aloha,
--
Jim Manico
@Manicode

> On Feb 15, 2016, at 5:34 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote:
> 
> In older systems, time based logout is all you have if you aren't assessing 
> risk. 
> 
> I would think over time will quickly diminish in its importance (or as best 
> practice) - at least as the single method for determine a session should end 
> other than explicit logout. 
> 
> Phil
> 
>> On Feb 15, 2016, at 16:22, Jim Manico <j...@manicode.com> wrote:
>> 
>> Polite comment, Google in general is pretty "open" about session management 
>> in general - long idle timeout and no apparent absolute timeout. For a bank 
>> or other organization that produces high risk software, this is not standard 
>> practice. Re-authentication is a critical security boundary, not prompting 
>> the user for re-authentication credentials is unacceptable in those 
>> environments.
>> 
>> I may be jumping in out of context, but fair?
>> 
>> --
>> Jim Manico
>> @Manicode
>> +1 (808) 652-3805
>> 
>>> On Feb 15, 2016, at 3:36 PM, William Denniss <wdenn...@google.com> wrote:
>>> 
>>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
>>> Connect), e.g.:
>>> 
>>> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
>>> 
>>> The reason we do this is to be explicit about how we are processing the 
>>> "max_age" reauth request, specifically that we don't always prompt the user 
>>> to reauthenticate directly (but do perform in-session risk analysis).
>>> 
>>> I can see us potentially using the more generic amr values like "user", and 
>>> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
>>> avoid brittle relationships with RPs. That said, I don't object to those 
>>> being in the registry, perhaps there is value in some tightly coupled 
>>> enterprise configurations.
>>> 
>>> 
>>>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
>>>> <tors...@lodderstedt.net> wrote:
>>>> Hi Denniss,
>>>> 
>>>> out of curiosity: Does Google use amr values? 
>>>> 
>>>> best regards,
>>>> Torsten.
>>>> 
>>>> 
>>>>> Am 14.02.2016 um 02:40 schrieb William   Denniss:
>>>>> 
>>>>> 
>>>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones 
>>>>> <michael.jo...@microsoft.com> wrote:
>>>>>> It's an acceptable fallback option if the working group decides it 
>>>>>> doesn't want to register the values that are already in production use 
>>>>>> at the time we establish the registry. But add William points out, 
>>>>>> Google is already using some of these values. Microsoft is using some of 
>>>>>> them. The OpenID MODRNA specs are using some of them. So it seems more 
>>>>>> efficient to register them at the same time.
>>>>>> 
>>>>>> That would be my preference.
>>>>> 
>>>>> +1, it is also my preference to register the current values.
>>>>> 
>>>>> I don't see any harm in the spec that establishes the registry also 
>>>>> seeding it with all known values in use at the time of drafting, 
>>>>> regardless of the group that originally specified them. Makes the 
>>>>> original spec more useful, and avoids the need to submit each value for 
>>>>> consideration separately – they can be all be reviewed at the same time. 
>>>>> 
>>>>> 
>>>>>> From: Justin Richer
>>>>>> Sent: ‎2/‎13/‎2016 11:11 AM
>>>>>> To: Phil Hunt
>>>>>> 
>>>>>> Cc: <oauth@ietf.org>
>>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>>>>>> Adoption Finalized
>>>>>> 
>>>>

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[Jim Manico]

Polite comment, Google in general is pretty "open" about session management in 
general - long idle timeout and no apparent absolute timeout. For a bank or 
other organization that produces high risk software, this is not standard 
practice. Re-authentication is a critical security boundary, not prompting the 
user for re-authentication credentials is unacceptable in those environments.

I may be jumping in out of context, but fair?

--
Jim Manico
@Manicode
+1 (808) 652-3805

> On Feb 15, 2016, at 3:36 PM, William Denniss <wdenn...@google.com> wrote:
> 
> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
> Connect), e.g.:
> 
> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
> 
> The reason we do this is to be explicit about how we are processing the 
> "max_age" reauth request, specifically that we don't always prompt the user 
> to reauthenticate directly (but do perform in-session risk analysis).
> 
> I can see us potentially using the more generic amr values like "user", and 
> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
> avoid brittle relationships with RPs. That said, I don't object to those 
> being in the registry, perhaps there is value in some tightly coupled 
> enterprise configurations.
> 
> 
>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
>> <tors...@lodderstedt.net> wrote:
>> Hi Denniss,
>> 
>> out of curiosity: Does Google use amr values? 
>> 
>> best regards,
>> Torsten.
>> 
>> 
>>> Am 14.02.2016 um 02:40 schrieb William Denniss:
>>> 
>>> 
>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <michael.jo...@microsoft.com> 
>>> wrote:
>>>> It's an acceptable fallback option if the working group decides it doesn't 
>>>> want to register the values that are already in production use at the time 
>>>> we establish the registry. But add William points out, Google is already 
>>>> using some of these values. Microsoft is using some of them. The OpenID 
>>>> MODRNA specs are using some of them. So it seems more efficient to 
>>>> register them at the same time.
>>>> 
>>>> That would be my preference.
>>> 
>>> +1, it is also my preference to register the current values.
>>> 
>>> I don't see any harm in the spec that establishes the registry also seeding 
>>> it with all known values in use at the time of drafting, regardless of the 
>>> group that originally specified them. Makes the original spec more useful, 
>>> and avoids the need to submit each value for consideration separately – 
>>> they can be all be reviewed at the same time. 
>>> 
>>> 
>>>> From: Justin Richer
>>>> Sent: ‎2/‎13/‎2016 11:11 AM
>>>> To: Phil Hunt
>>>> 
>>>> Cc: <oauth@ietf.org>
>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>>>> Adoption Finalized
>>>> 
>>>> Can we just do that, then? Seems to be the easiest way to address various 
>>>> needs and concerns. 
>>>> 
>>>>  — Justin
>>>> 
>>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.h...@oracle.com> 
>>>>> wrote:
>>>>> 
>>>>> Yes
>>>>> 
>>>>> Phil
>>>>> 
>>>>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" 
>>>>> <tors...@lodderstedt.net> wrote:
>>>>> 
>>>>>> So basically, the RFC could also just establish the new registry and 
>>>>>> oidf could feel in the values?
>>>>>> 
>>>>>> (just trying to understand)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  Originalnachricht 
>>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for 
>>>>>> Adoption Finalized
>>>>>> Von: Mike Jones <michael.jo...@microsoft.com>
>>>>>> An: tors...@lodderstedt.net,John Bradley <ve7...@ve7jtb.com>
>>>>>> Cc: oauth@ietf.org
>>>>>> 
>>>>>> The context that most people on this thread probably don’t have is that 
>>>>>> an IANA registry can only be established by an

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

[Jim Manico]

> And what about multiple confidential clients being set up with the same 
> id/secret. 

Bad idea. For security when you see one confidential client doing bad things 
you will need to revoke it individually. If multiple confidential clients have 
the same client secrets, thats no longer possible.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 4, 2015, at 8:01 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> 
> Hi All
> 
> I'm having a discussion with my colleagues on the pros and cons of sharing a 
> client_id.
> 
> For example, say we have N number of public mobile applications (the same 
> application package, an application instance on an individual phone), and one 
> approach is for each of these applications to have the same client_id.
> 
> I've been trying to analyze why it can be bad and the only thing I can come 
> up with is that there will be no (easy) way to track which application 
> instance actually accessed a given RS.
> 
> Can someone please explain what the pros and cons are of having the same 
> client_id shared between public client applications.
> 
> And what about multiple confidential clients being set up with the same 
> id/secret. I suspect it is a bad idea but what is main line why it is a bad 
> idea, lets say it is all done in the protected network, no chance of the bad 
> clients interfering...
> 
> 
> 
> Thanks, Sergey
> 
> ___
> 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] Better title for OAuth 2.0 JWT Authorization Request

[Jim Manico]

Ok then it looks like the name is good as is. :)

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Oct 15, 2015, at 6:52 AM, Nat Sakimura <n-sakim...@nri.co.jp> wrote:
> 
> That’s true, but RFC6749 uses the term Authorization request to mean the 
> request sent to the authorization endpoint.
>  
> See 4.1.1, 4.2.1, 4.3.1, 4.4.1 of RFC6749.
>  
> Best,
>  
> --
> Nat Sakimura <n-sakim...@nri.co.jp>
> Nomura Research Institute, Ltd.
>  
> PLEASE READ:
> The information contained in this e-mail is confidential and intended for the 
> named recipient(s) only.
> If you are not an intended recipient of this e-mail, you are hereby notified 
> that any review, dissemination, distribution or duplication of this message 
> is strictly prohibited. If you have received this message in error, please 
> notify the sender immediately and delete your copy from your system.
>  
> From: Jim Manico [mailto:j...@manicode.com] 
> Sent: Saturday, October 10, 2015 12:28 AM
> To: Nat Sakimura <n-sakim...@nri.co.jp>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Better title for OAuth 2.0 JWT Authorization Request
>  
> But its all authorization, even the token request
> 
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
> On Oct 9, 2015, at 5:23 PM, Nat Sakimura <n-sakim...@nri.co.jp> wrote:
> 
> The reason for saying authorization request is that there are two types of 
> requests in RFC6749; authorization request and token request. This draft 
> deals with the former and thus named JAR.  
>  
> Nat
> 
> 2015年10月9日金曜日、Jim Manico<j...@manicode.com>さんは書きました:
> The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Request".
> 
> --
> Jim Manico
> @Manicode
> (808) 652-3805
> 
> On Oct 9, 2015, at 3:43 AM, Nat Sakimura <n-sakim...@nri.co.jp> wrote:
> 
> Hi OAuthers:
>  
> One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 
> is to come up with a better title.
> The current title “OAuth 2.0 JWT Authorization Request (JAR)”, is somewhat 
> better than what it used to be, but if you can suggest a better name, I am 
> all for it.
> 
> Please let me know if you have an idea.
> 
> Best,
> --
> Nat Sakimura <n-sakim...@nri.co.jp>
> Nomura Research Institute, Ltd.
>  
> PLEASE READ:
> The information contained in this e-mail is confidential and intended for the 
> named recipient(s) only.
> If you are not an intended recipient of this e-mail, you are hereby notified 
> that any review, dissemination, distribution or duplication of this message 
> is strictly prohibited. If you have received this message in error, please 
> notify the sender immediately and delete your copy from your system.
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Server / Resource Server Coordination

[Jim Manico]

This seems like a reasonable approach. Isn't the whole idea of the auth 
server/resource server separation in OAuth 2.0 so that one auth server can 
govern multiple resource servers?

--
Jim Manico
@Manicode

> On Oct 13, 2015, at 6:13 AM, Ofer Nave <odig...@gmail.com> wrote:
> 
> I know the OAuth 2.0 RFC doesn't specify any standards for coordination 
> between the Authorization Server and the Resource Server, as it's generally 
> assumed that both will be owned or operated by the same entity.
> 
> However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature 
> to make it easy for other API developers to delegate to me the responsibility 
> of handling the auth grant process and issuing access tokens.
> 
> It seems to me that a simple version of this could be easily done by:
> 
> 1) Defining an Access Token format that contains within it everything a 
> Resource Server will need to validate it and determine the level of access 
> granted (list of scopes, expiration datetime, HMAC signature using a shared 
> secret).
> 
> 2) Providing a means (basic web UI) for Resource Server owners to register a 
> set of scopes for their service, along with user-understandable descriptions 
> of each to display when they arrive at my Authorization Endpoint.
> 
> While I've read the relevant RFCs, I'm new to the OAuth domain, and would 
> appreciate any feedback. Is this a stupid idea?  Is this a good idea, but 
> redundant with another standard I'm not aware of?
> 
> -ofer
> ___
> 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] Better title for OAuth 2.0 JWT Authorization Request

[Jim Manico]

But its all authorization, even the token request

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Oct 9, 2015, at 5:23 PM, Nat Sakimura <n-sakim...@nri.co.jp> wrote:
> 
> The reason for saying authorization request is that there are two types of 
> requests in RFC6749; authorization request and token request. This draft 
> deals with the former and thus named JAR.  
> 
> Nat
> 
> 2015年10月9日金曜日、Jim Manico<j...@manicode.com>さんは書きました:
>> The word authorization is implied by OAuth, consider "OAuth 2.0 JWT Request".
>> 
>> --
>> Jim Manico
>> @Manicode
>> (808) 652-3805
>> 
>>> On Oct 9, 2015, at 3:43 AM, Nat Sakimura <n-sakim...@nri.co.jp> wrote:
>>> 
>>> Hi OAuthers:
>>> 
>>>  
>>> 
>>> One of the to do for https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 
>>> is to come up with a better title.
>>> 
>>> The current title “OAuth 2.0 JWT Authorization Request (JAR)”, is somewhat 
>>> better than what it used to be, but if you can suggest a better name, I am 
>>> all for it. 
>>> 
>>> Please let me know if you have an idea.
>>> 
>>> Best,
>>> 
>>> --
>>> 
>>> Nat Sakimura <n-sakim...@nri.co.jp>
>>> 
>>> Nomura Research Institute, Ltd.
>>> 
>>>  
>>> 
>>> PLEASE READ:
>>> 
>>> The information contained in this e-mail is confidential and intended for 
>>> the named recipient(s) only.
>>> 
>>> If you are not an intended recipient of this e-mail, you are hereby 
>>> notified that any review, dissemination, distribution or duplication of 
>>> this message is strictly prohibited. If you have received this message in 
>>> error, please notify the sender immediately and delete your copy from your 
>>> system.
>>> 
>>>  
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico]

This is all contextual to the application. In some situations I want to 
immediately force re-authentication for all transactions above X$ such 
as banking applications. In some situations I want a permanent refresh 
token, like for Twitter like social applications. etc...etc...


- Jim Manico



On 8/28/15 10:58 AM, William Denniss wrote:

+1 for John's suggestion.

Why force users to re-authenticate after an arbitrary 30-day window?

On Fri, Aug 28, 2015 at 1:41 PM John Bradley ve7...@ve7jtb.com 
mailto:ve7...@ve7jtb.com wrote:


I would use a 5 min AT and roll the refresh token per
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry
if that is what you want for a inactivity timeout after which the
user must authenticate again.   The user can always revoke the
refresh token.

Rolling the refresh token also has the advantage that if the token
leaks or is stollen then you will detect the second use of the
expired refresh token and invalidate both, so the user needs to
loggin.

In general I think rolling the refresh token is a good idea though
it is not popular, I think it is more secure.

John B.




On Aug 28, 2015, at 11:21 AM, Donghwan Kim
flowersinthes...@gmail.com mailto:flowersinthes...@gmail.com
wrote:

I'm sorry to introduce a common topic.

As John has suggested, I'm going to design that

* An access token should be short lived e.g. 5 minutes (not to
hit the AS to verify the token or 1 hour (to hit the AS to verify
the token). I'm inclined to 5 minutes for stateless architecture
of RSs.
* A refresh token should have 1 month of expiration time by
default. If it turns out that some access token expired, its
refresh token should refresh the token. Then, so called
persistent login can be implemented regardless of the form of
authentication. Only if it fails for some reason e.g. token
revocation or inactivity for 1 month, a user is logged out
automatically and should log in again.
* A refresh token should be able to be revoked somehow. With 5
minutes approach, it will invalidate only the refresh token (Yes
the attacker can have 5 minutes at most), and with 1 hour
approach, it will invalidate the refresh token as well as the
corresponding access token.

Thanks,

-- Donghwan

On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:

Refresh tokens are also used by public clients, e.g. native
apps. OIDC allows to acquire a new id token from a refresh
token as well. Note: this does not mean a fresh
authentication but a refreshed id token containing the data
of the original authentication transaction.

Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley
ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com:

I think Nat’s diagram about the problems of doing pseudo
authentication with OAuth is being taken out of context.

The refresh token dosen’t expire, it is revoked by the
user or system.  In some cases refresh tokens are
automatically revoked if the users session to the AS
ends.  I think AOL typically revokes refresh tokens when
sessions terminate.

OpenID Connect provides a separate id_token with a
independent lifetime from the refresh token.  A client
may keep a refresh token for a much longer time than the
user has a login session with the AS.

Refresh tokens are typically used by confidential clients
that are using a client secret in combination with the
refresh token for getting a new access token.

By design access tokens should be short lived as the AS
is expected to have a way of revoking refresh tokens but
not access tokens.
A access token that dosen't expire , and can’t be revoked
is not a good idea.

John B.



On Aug 24, 2015, at 2:41 AM, Donghwan Kim
flowersinthes...@gmail.com
mailto:flowersinthes...@gmail.com wrote:

Hi,

According to Figure 2 from
http://tools.ietf.org/html/rfc6749#section-1.5, refresh
token can be used to refresh an expired access token
without requesting resource owner to sign in again
(uncomfortable experience). However, if it's true, isn't
it that refresh token might be used to request a new
access token even years later? and then isn't refresh
token the same with access token which never expires?

I intended to use refresh token to implement persistent
login by sending a refresh request before issued access
token expires (expires_in runs out). But if refresh
token works even

Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico]

Again, I would state that this is all contextual to the application 
being built - which is why the RFC never gives specific times other than 
short lived or long lived. I would suggest giving a series of 
recommendations relative to a few different risk profiles (low risk, 
social media, banking, enterprise, etc) as opposed to one recommendation.


With respect,
Jim Manico

On 8/28/15 10:41 AM, John Bradley wrote:
I would use a 5 min AT and roll the refresh token per 
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if 
that is what you want for a inactivity timeout after which the user 
must authenticate again.   The user can always revoke the refresh token.


Rolling the refresh token also has the advantage that if the token 
leaks or is stollen then you will detect the second use of the expired 
refresh token and invalidate both, so the user needs to loggin.


In general I think rolling the refresh token is a good idea though it 
is not popular, I think it is more secure.


John B.



On Aug 28, 2015, at 11:21 AM, Donghwan Kim 
flowersinthes...@gmail.com mailto:flowersinthes...@gmail.com wrote:


I'm sorry to introduce a common topic.

As John has suggested, I'm going to design that

* An access token should be short lived e.g. 5 minutes (not to hit 
the AS to verify the token or 1 hour (to hit the AS to verify the 
token). I'm inclined to 5 minutes for stateless architecture of RSs.
* A refresh token should have 1 month of expiration time by default. 
If it turns out that some access token expired, its refresh token 
should refresh the token. Then, so called persistent login can be 
implemented regardless of the form of authentication. Only if it 
fails for some reason e.g. token revocation or inactivity for 1 
month, a user is logged out automatically and should log in again.
* A refresh token should be able to be revoked somehow. With 5 
minutes approach, it will invalidate only the refresh token (Yes the 
attacker can have 5 minutes at most), and with 1 hour approach, it 
will invalidate the refresh token as well as the corresponding access 
token.


Thanks,

-- Donghwan

On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt 
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:


Refresh tokens are also used by public clients, e.g. native apps.
OIDC allows to acquire a new id token from a refresh token as
well. Note: this does not mean a fresh authentication but a
refreshed id token containing the data of the original
authentication transaction.

Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley
ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com:

I think Nat’s diagram about the problems of doing pseudo
authentication with OAuth is being taken out of context.

The refresh token dosen’t expire, it is revoked by the user
or system.  In some cases refresh tokens are automatically
revoked if the users session to the AS ends.  I think AOL
typically revokes refresh tokens when sessions terminate.

OpenID Connect provides a separate id_token with a
independent lifetime from the refresh token.  A client may
keep a refresh token for a much longer time than the user has
a login session with the AS.

Refresh tokens are typically used by confidential clients
that are using a client secret in combination with the
refresh token for getting a new access token.

By design access tokens should be short lived as the AS is
expected to have a way of revoking refresh tokens but not
access tokens.
A access token that dosen't expire , and can’t be revoked is
not a good idea.

John B.



On Aug 24, 2015, at 2:41 AM, Donghwan Kim
flowersinthes...@gmail.com
mailto:flowersinthes...@gmail.com wrote:

Hi,

According to Figure 2 from
http://tools.ietf.org/html/rfc6749#section-1.5, refresh
token can be used to refresh an expired access token without
requesting resource owner to sign in again (uncomfortable
experience). However, if it's true, isn't it that refresh
token might be used to request a new access token even years
later? and then isn't refresh token the same with access
token which never expires?

I intended to use refresh token to implement persistent
login by sending a refresh request before issued access
token expires (expires_in runs out). But if refresh token
works even if access token expired already, sending a
refresh request on application start up would be enough.

So I'm not sure what I'm missing about refresh token as well
as how to implement persistent login using it (you can
regard authentication here pseudo-authentication illustrated
in

https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico]

I stand corrected, the RFC does give specific time recommendations such 
as 10 minutes authorization code recommendation here 
https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall 
point is still valid. :)


Aloha,
Jim




On 8/28/15 11:36 AM, Jim Manico wrote:
Again, I would state that this is all contextual to the application 
being built - which is why the RFC never gives specific times other 
than short lived or long lived. I would suggest giving a series of 
recommendations relative to a few different risk profiles (low risk, 
social media, banking, enterprise, etc) as opposed to one recommendation.


With respect,
Jim Manico

On 8/28/15 10:41 AM, John Bradley wrote:
I would use a 5 min AT and roll the refresh token per 
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if 
that is what you want for a inactivity timeout after which the user 
must authenticate again.   The user can always revoke the refresh token.


Rolling the refresh token also has the advantage that if the token 
leaks or is stollen then you will detect the second use of the 
expired refresh token and invalidate both, so the user needs to loggin.


In general I think rolling the refresh token is a good idea though it 
is not popular, I think it is more secure.


John B.



On Aug 28, 2015, at 11:21 AM, Donghwan Kim 
flowersinthes...@gmail.com mailto:flowersinthes...@gmail.com wrote:


I'm sorry to introduce a common topic.

As John has suggested, I'm going to design that

* An access token should be short lived e.g. 5 minutes (not to hit 
the AS to verify the token or 1 hour (to hit the AS to verify the 
token). I'm inclined to 5 minutes for stateless architecture of RSs.
* A refresh token should have 1 month of expiration time by default. 
If it turns out that some access token expired, its refresh token 
should refresh the token. Then, so called persistent login can be 
implemented regardless of the form of authentication. Only if it 
fails for some reason e.g. token revocation or inactivity for 1 
month, a user is logged out automatically and should log in again.
* A refresh token should be able to be revoked somehow. With 5 
minutes approach, it will invalidate only the refresh token (Yes the 
attacker can have 5 minutes at most), and with 1 hour approach, it 
will invalidate the refresh token as well as the corresponding 
access token.


Thanks,

-- Donghwan

On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt 
tors...@lodderstedt.net wrote:


Refresh tokens are also used by public clients, e.g. native
apps. OIDC allows to acquire a new id token from a refresh token
as well. Note: this does not mean a fresh authentication but a
refreshed id token containing the data of the original
authentication transaction.

Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley
ve7...@ve7jtb.com:

I think Nat’s diagram about the problems of doing pseudo
authentication with OAuth is being taken out of context.

The refresh token dosen’t expire, it is revoked by the user
or system.  In some cases refresh tokens are automatically
revoked if the users session to the AS ends.  I think AOL
typically revokes refresh tokens when sessions terminate.

OpenID Connect provides a separate id_token with a
independent lifetime from the refresh token.  A client may
keep a refresh token for a much longer time than the user
has a login session with the AS.

Refresh tokens are typically used by confidential clients
that are using a client secret in combination with the
refresh token for getting a new access token.

By design access tokens should be short lived as the AS is
expected to have a way of revoking refresh tokens but not
access tokens.
A access token that dosen't expire , and can’t be revoked is
not a good idea.

John B.



On Aug 24, 2015, at 2:41 AM, Donghwan Kim
flowersinthes...@gmail.com wrote:

Hi,

According to Figure 2 from
http://tools.ietf.org/html/rfc6749#section-1.5, refresh
token can be used to refresh an expired access token
without requesting resource owner to sign in again
(uncomfortable experience). However, if it's true, isn't it
that refresh token might be used to request a new access
token even years later? and then isn't refresh token the
same with access token which never expires?

I intended to use refresh token to implement persistent
login by sending a refresh request before issued access
token expires (expires_in runs out). But if refresh token
works even if access token expired already, sending a
refresh request on application start up would be enough.

So I'm not sure what I'm missing about refresh token as
well as how to implement persistent login using it (you can

Re: [OAUTH-WG] Lifetime of refresh token

[Jim Manico]

There is a good debate and discussion on refresh tokens on StackOverflow. 

http://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens

Is this a good place to send developers to answer refresh token questions, and 
if not, can the illustrious smart people on this list update StackOverflow if 
necessary?

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

 On Aug 23, 2015, at 11:41 PM, Donghwan Kim flowersinthes...@gmail.com wrote:
 
 Hi,
 
 According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5, 
 refresh token can be used to refresh an expired access token without 
 requesting resource owner to sign in again (uncomfortable experience). 
 However, if it's true, isn't it that refresh token might be used to request a 
 new access token even years later? and then isn't refresh token the same with 
 access token which never expires?
 
 I intended to use refresh token to implement persistent login by sending a 
 refresh request before issued access token expires (expires_in runs out). But 
 if refresh token works even if access token expired already, sending a 
 refresh request on application start up would be enough.
 
 So I'm not sure what I'm missing about refresh token as well as how to 
 implement persistent login using it (you can regard authentication here 
 pseudo-authentication illustrated in 
 https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg).
  What is the lifetime of refresh token?
 
 Thanks,
 
 -- Donghwan
 ___
 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