Re: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01

[Hannes Tschofenig]

Hi Mike,

thanks for the response. I am fine with your explanations.

Ciao
Hannes

On 09/03/2016 02:00 AM, Mike Jones wrote:

Thanks for your review, Hannes.  Replies are inline...

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 3, 2016 12:51 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-01

Hi Mike, Phil, Tony,

I have read through draft-ietf-oauth-amr-values-01. My earlier comments have 
been addressed.

As a shepherd I nevertheless have a few questions/remarks:

1) The term 'multiple-channel authentication' is unfamiliar to me.
Could you give me an example or a reference to a specification?

https://www.ldapwiki.com/wiki/Multiple-channel%20Authentication has a clear 
explanation.  However, I'm reluctant to reference a wiki page that may be 
transient from an RFC.  If anyone out there has a more stable reference to 
suggest, please do so.  Instead, I've added this example text for -02:

For instance, a multiple-channel authentication might involve both 
entering information into
a workstation's browser and providing information on a telephone 
call to a pre-registered number.

2) PIN: The use of RFC 2119 language appears to be inappropriate.

Thanks, will be fixed in -02.

3) Could you explain me what 'risk-based authentication' is? While you provided 
a reference

https://en.wikipedia.org/wiki/Risk-based_authentication has a clear explanation.  Bruce 
Schneier writes about it in a blog post here 
https://www.schneier.com/blog/archives/2013/11/risk-based_auth.html.  Deloitte has a 
primer at http://deloitte.wsj.com/cio/2013/10/30/risk-based-authentication-a-primer/.  
There's lots of material on the web and the term is pretty widely known in 
authentication/identity circles.  Unfortunately, as with "mca", I don't know of 
a great authoritative reference to cite.  Any suggestions out there?

4) Could we generalize the term 'wia' to operating systems other than Windows 
as well?

I don't think so.  It consists of a particular set of documented protocol 
interactions, as describe at 
http://blogs.msdn.com/b/benjaminperkins/archive/2011/09/14/iis-integrated-windows-authentication-with-negotiate.aspx.
  That said, because these protocols are publicly documented, other systems 
(maybe SAMBA?) may have also implemented it.

5) I am not sure whether all normative references indeed need to be declared as 
such.
For example, 'otp' is defined in a very generic fashion but you list HTOP, and 
TOTP as normative references.
I would rather see HTOP and TOTP as a standardized examples of 
one-time-passwords. IMHO the story would be different if you indeed want to 
differentiate between the different technical mechanisms itself. This is a 
reasonable approach as well if the security differences between the mechanisms 
is important for the given application.

If use cases arise in which applications want to define additional "amr" values "hotp" 
and/or "totp", they can use the registry established by this application to do so.  It's explicitly 
not a goal of this specification to define all practical values.  Rather, it defines a few values that are 
actually in production use and even more importantly, establishes the registry for defining more, as needed 
in practice.

Ciao
Hannes


Thanks again,
-- Mike





___
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 
> *To:* John Bradley 
> *Cc:* Oleg Gryb ; Adam Lewis
> ; OAuth WG 
> *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 > > 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  
>> *To:* Oleg Gryb  ;
>> Adam Lewis 
>> 
>> *Cc:* OAuth WG  
>> *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
>> 

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

[Oleg Gryb]

"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 
 To: John Bradley  
Cc: Oleg Gryb ; Adam Lewis ; 
OAuth WG 
 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  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 
 To: Oleg Gryb ; Adam Lewis  
 Cc: OAuth WG 
 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 
 To: Adam Lewis  
 Cc: OAuth WG 
 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  
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 totoken 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 

Re: [OAUTH-WG] Following up on token exchange use case

[Anthony Nadalin]

Things have gotten so muddled not sure where to begin, the original goal of 
this draft was to provide the function that we use in daily high volume 
production of WS-Trust as we transition to Oauth.  WS-Trust provided many 
options, one was ActAs and the other was OnBehalfOf, these were 2 distinct 
functions but could be combined (and thus the results are of a composite 
nature). There were also other options like delegateTo, Forwardable and 
Delegatable. So we have use cases for all these.

So we have straight forward scenarios for (1) a token request to be on behalf 
of a given/specified token, we also have a straight forward scenario for (2) 
requesting a token based upon a specific token. We also have complex scenarios 
for combining the semantics of both  (1) and (2) where the token request is on 
behalf of a specific token and the request is based upon a specific token, this 
happened a lot in our server to server scenarios for access to backend 
documents and services. Where we have chained services this is where the 
delegateTo, Forwardable and Delegatable options come into the scenario.

The way that this current specification is structured and written the Subject 
is always required which is a not a good thing since there may not be a 
subject, as basic token requests don’t have to have subjects (just 
authentication credentials), thus you can’t get the semantics of (2) without 
(1). Now the semantics of combing (1) and (2) seem to be not understood and 
wanting to be removed.


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell 
Cc:  
Subject: Re: [OAUTH-WG] Following up on token exchange use case

No objections. Simplification is better, and this spec is already fairly 
convoluted with all the options turned on.

 — Justin

On Aug 26, 2016, at 1:30 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Looking for two things here:
1) Any objections to removing the want_composite request parameter? Please 
explain, if so. I plan to remove it in the next draft barring an outpouring of 
support to keep it.
2) Tony to explain his use case and describe what changes would be needed to 
accommodate it.

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
During the meeting in Berlin Tony voiced concern about a use case he had for 
token exchange. Honestly, it's still not entirely clear to me what that use 
case is or what would need to change in support of it. I'd like to better 
understand the use case and see if it's something that can reasonably be 
accommodated with Token Exchange. During the meeting Tony referred back to an 
earlier email where he said, "want_composite is not really the effect we are 
looking for since it provides for a single token, the use case we have is where 
you want the ability to use the subject_token and the actor_token in 
combination and not as a composite of only the claims."
The want_composite parameter came about during some iterative work on the 
document (between I-D publications) last year. At first the client could 
express that it wanted a composite token, one containing delegation semantics, 
with the inclusion of the actor_token parameter. One of the other editors 
suggested, however, that the actor_token token might be necessary for 
authorization in cases even when the client wasn't asking for a composite token 
and that placing the desire for delegation semantics on it was overloading the 
parameter too much. I introduced the want_composite parameter to give the 
client such a signal independent of the actor_token parameter. My (admittedly 
incomplete) understanding of WS-Trust is that the client/requester can make 
such an indication and I was trying to follow that model. However, I'm not sure 
it's needed or even makes much much sense. Ultimately it's the server's 
decision about how to construct the issued token and what to include in it. It 
is the server's policy, not a client signal, which makes the determination. So 
the want_composite parameter is really just noise that makes the spec longer. 
And, from the quote above, seems might also lead some readers to incorrect 
conclusions about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.


___
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] 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 > > 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 
>>> *To:* Oleg Gryb ; Adam Lewis
>>> 
>>> *Cc:* OAuth WG 
>>> *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  
 *To:* Adam Lewis 
 
 *Cc:* OAuth WG  
 *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
 >>> > 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 st

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

[John Bradley]

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  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  
>> To: Oleg Gryb  ; Adam Lewis 
>>   
>> Cc: OAuth WG  
>> 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  
>>> To: Adam Lewis  
>>>  
>>> Cc: OAuth WG  
>>> 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 >> > 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 
>>> 
>>> 
>>> 
>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.manicode.com 
>> ___
>> OAuth mailing list
>> OAuth@iet

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 
> *To:* Oleg Gryb ; Adam Lewis
> 
> *Cc:* OAuth WG 
> *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  
>> *To:* Adam Lewis 
>> 
>> *Cc:* OAuth WG  
>> *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
>> > > 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
>>
>>
>
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.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

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

[Oleg Gryb]

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 
 To: Oleg Gryb ; Adam Lewis  
Cc: OAuth WG 
 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 
 To: Adam Lewis  
 Cc: OAuth WG 
 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  
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
  
 

   
 
 -- 
Jim Manico
Manicode Security
https://www.manicode.com 
___
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] best practices for implicit grant / token storage

[Jim Manico]

> 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 
> *To:* Adam Lewis 
> *Cc:* OAuth WG 
> *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
>  > 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
>
>

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

[Oleg Gryb]

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 
 To: Adam Lewis  
Cc: OAuth WG 
 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  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


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

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

[OAUTH-WG] Initial Working Group Draft of OAuth Token Binding Specification

[Mike Jones]

The initial working group draft of the OAuth Token Binding specification has 
been published.  It has the same content as draft-jones-oauth-token-binding-00, 
but with updated references.  This specification defines how to perform token 
binding for OAuth access tokens and refresh tokens.  Note that the access token 
mechanism is expected to change shortly to use the Referred Token Binding, per 
working group discussions at IETF 96 in Berlin.

The specification is available at:

*   http://tools.ietf.org/html/draft-ietf-oauth-token-binding-00

An HTML-formatted version is also available at:

*   http://self-issued.info/docs/draft-ietf-oauth-token-binding-00.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1605 and as 
@selfissued.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Adam Lewis]

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-WG] I-D Action: draft-ietf-oauth-token-binding-00.txt

[internet-drafts]

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

Title   : OAuth 2.0 Token Binding
Authors : Michael B. Jones
  John Bradley
  Brian Campbell
Filename: draft-ietf-oauth-token-binding-00.txt
Pages   : 11
Date: 2016-09-07

Abstract:
   This specification enables OAuth 2.0 implementations to apply Token
   Binding to Access Tokens and Refresh Tokens.  This cryptographically
   binds these tokens to the TLS connections over which they are
   intended to be used.  This use of Token Binding protects these tokens
   from man-in-the-middle and token export and replay attacks.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [OAUTH-WG] Working Group Last Call on "Authentication Method Reference Values"

[Vladimir Dzhuvinov]

Thanks Mike, "hwk" and "swk" would do. The actual auth method is indeed
proving key possession, whereas x.509 is mostly about formatting.

Vladimir


On 03/09/16 01:20, Mike Jones wrote:
> Thanks for your question, Vladimir.  No, there is not currently an 
> X.509-specific value defined.  However, there are these related values:
>
>hwk
>   Proof-of-possession (PoP) of a hardware-secured key.  See
>   Appendix C of [RFC4211] for a discussion on PoP.
>
>swk
>   Proof-of-possession (PoP) of a software-secured key.  See
>   Appendix C of [RFC4211] for a discussion on PoP.
>
> Given that x.509 authentication is PoP authentication, these might apply, 
> depending upon your use case.  Are you using an X.509 "amr" value in 
> practice?  Remember that even if such a value isn't already in use now, if it 
> is ever need in the future, it can always be added later via the registry 
> established by this specification.
>
>   Thanks again,
>   -- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
> Sent: Wednesday, July 27, 2016 8:14 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Working Group Last Call on "Authentication Method 
> Reference Values"
>
>
>
> On 18/07/16 17:30, Hannes Tschofenig wrote:
>> Hi all,
>>
>> this is a Last Call for comments on the "Authentication Method 
>> Reference Values" specification.
>>
>> The document can be found here:
>> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-01
>>
>> Please have your comments in no later than August 1st.
> Thanks Hannes.
>
> Do we have an "amr" value for x.509 certificate based authentication?
>
>> Ciao
>> Hannes & Derek
>>
> --
> Vladimir Dzhuvinov
>
>

-- 
Vladimir Dzhuvinov :: vladi...@connect2id.com




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