Re: [OAUTH-WG] SPA applications best practice

[Samuel Erdtman]

Hi Jim,

If there is enough information I think such RFC could be interesting in the
same way as  "OAuth 2.0 for Native Apps" (
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07) is for native
app.

To see if the group also thinks so I would suggest to create a personal
draft and ask it to be adopted as a working group item. (I´ll send you a
direct message with some details on how to do that)

Best Regards
Samuel Erdtman


On Mon, Feb 27, 2017 at 3:17 PM, Jim Manico  wrote:

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.txt

[William Denniss]

My coauthors and I posted draft 04 of the OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices draft today.

Key changes:

   1. Title updated to reflect specificity of devices that use this flow.
   2. User interaction section expanded.
   3. OAuth 2.0 Metadata
    for the device
   authorization endpoint added.
   4. User interaction section expanded.
   5. Security Considerations section added.
   6. Usability Considerations section added.

Please give it a look!

On Mon, Feb 27, 2017 at 9:46 AM,  wrote:

>
> 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 Device Flow for Browserless and Input
> Constrained Devices
> Authors : William Denniss
>   John Bradley
>   Michael B. Jones
>   Hannes Tschofenig
> Filename: draft-ietf-oauth-device-flow-04.txt
> Pages   : 15
> Date: 2017-02-27
>
> Abstract:
>This OAuth 2.0 authorization flow for browserless and input
>constrained devices, often referred to as the device flow, enables
>OAuth clients to request user authorization from devices that have an
>Internet connection, but don't have an easy input method (such as a
>smart TV, media console, picture frame, or printer), or lack a
>suitable browser for a more traditional OAuth flow.  This
>authorization flow instructs the user to perform the authorization
>request on a secondary device, such as a smartphone.  There is no
>requirement for communication between the constrained device and the
>user's secondary device.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.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 Device Flow for Browserless and Input 
Constrained Devices
Authors : William Denniss
  John Bradley
  Michael B. Jones
  Hannes Tschofenig
Filename: draft-ietf-oauth-device-flow-04.txt
Pages   : 15
Date: 2017-02-27

Abstract:
   This OAuth 2.0 authorization flow for browserless and input
   constrained devices, often referred to as the device flow, enables
   OAuth clients to request user authorization from devices that have an
   Internet connection, but don't have an easy input method (such as a
   smart TV, media console, picture frame, or printer), or lack a
   suitable browser for a more traditional OAuth flow.  This
   authorization flow instructs the user to perform the authorization
   request on a secondary device, such as a smartphone.  There is no
   requirement for communication between the constrained device and the
   user's secondary device.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-04


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] review draft-ietf-oauth-native-apps-07

[Samuel Erdtman]

Thanks for the replies.

If there are no formal guidelines from IETF I think we should just proceed
it is a good and informative spec, it was just to me it felt slightly of.

Based on the conversation I have no objections taking this draft to RFC.

//Samuel

On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer  wrote:

> When I brought RFCs 7591, 7592, and 7662 up through the finalization
> process, I learned that there are two camps out there on normative
> requirements in the security considerations section. Some like them, as
> long as they don’t contradict requirements/advice in previous sections, and
> some don’t like them, preferring all normative material be in the “body” of
> the spec itself. I was given the impression that it was more of a stylistic
> choice than anything, but I can only speak from my personal experience.
>
>  — Justin
>
> On Feb 21, 2017, at 3:17 PM, William Denniss  wrote:
>
> The only real requirement in that section I guess is the use of PKCE
> (8.2).  That requirement could be moved to the body of the doc, while
> keeping the longer discussing around code interception in the security
> considerations.  To me the remaining text are indeed security best
> practices / clarifications.
>
> Other OAuth WG RFCs have requirement level capitalization in the Security
> Section like RFC7591. I always assumed these were best-practice security
> requirements. But if the style is really not to do this, the requirement
> level capitalization could be dropped from that section in the native apps
> BCP.
>
> On Tue, Feb 21, 2017 at 12:50 AM, Denis  wrote:
>
>>
>> I *don't thin**k* it's normal to have normative text in the Security
>> Considerations, hence I support Samuel's position.
>>
>> Let us look at the first MUST from RFC 6749 in the Security
>> Considerations section:
>>
>>The authorization server *MUST *authenticate the client *whenever 
>> possible*.
>> This sentence is incorrect. The right sentence should be :
>>
>>The authorization server *should *authenticate the client whenever 
>> possible.
>>
>> RFC 6749 is not an example to follow.
>>
>> Denis
>>
>>
>> I do think it's normal to have normative text in the Security
>> Considerations.  RFC6749 has a lengthy Security Considerations section
>>  with a lot of normative
>> text.
>>
>> Think of it this way: Sections 4 to 7 describe how to use native app URI
>> schemes to perform OAuth flows from the app to browser and back. If you
>> only read those sections, you could have a functioning (but potentially
>> insecure) OAuth flow in a native app. The security section adds some
>> security requirements and clarifications for implementing Sections 4-7,
>> like using PKCE, and more.
>>
>> Reviewing sub-section by sub-section:
>>
>> 8.1 Definitely belongs here, as the the whole BCP is about native-app URI
>> schemes, whereas doing OAuth in a WebView doesn't need those (as the client
>> can just pluck out the code from any redirect URI)
>> 8.2 Requires that servers who want to follow the native apps BCP support
>> PKCE, and recommends that they reject requests from clients who don't.
>> This *could* be in the main doc, but since PKCE is an existing thing, and
>> is purely additive from a security perspective, I think this reference
>> works fine. Originally I talked about PKCE more in the doc body, but some
>> reviewers thought it was then a little duplicative of the PKCE doc itself.
>> 8.3 This reads like classic security considerations to me, clarifying
>> some details of 7.3
>> 8.4 Part of this reads a little new-ish, regarding distinguishing native
>> clients from web ones. But on review, I think could just be re-worded to
>> reference RFC6749 Section 2.1.
>> 8.5 This one belongs where it is since the body of the BCP is talking
>> about the code flow.
>> 8.6 Totally belongs.
>> 8.7 to 8.11 belong IMO, they are security clarifications of long-standing
>> topics.
>>
>> My methodology when reviewing this was: is the text introducing a new
>> topic directly related to native apps or sections 4-7, or does it discuss
>> an old security topic in the context of native apps, or add security
>> related discussions of the content in 4-7. Of all those, I really only see
>> a bit of new topic related to native apps in 8.4, and in actual fact it
>> that sub-section should probably be reworded since RFC6749 already
>> establishes the public client type, which native apps are and a reference
>> would be more appropriate (which would reduce it to just clarifying an old
>> topic).
>>
>> What do you think of this analysis? Do you have any specific sections or
>> text you feel are better suited in the document body?  I will take an
>> action item to revise section 8.4.
>>
>> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman 
>> wrote:
>>
>>> Hi,
>>>
>>> I just had a question on best practice. In this document a large part of
>>> the normative text is located under Security Considerations.
>>>
>>> I had previou

[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

[OAUTH-WG] review draft-ietf-oauth-native-apps-07

[Sebastian.Ebling]

Hi all,

I have a question that relates to section B.2. Android Implementation Details.

I understand this as a working group best practice. Unfortunately this does not 
necessarily meet the Google instruction for Android. There is a lot of 
documentation out there pointing to the Android Account Manager and I do not 
get these both together.

Any idea?

Best Regards

Sebastian

-- 
Sebastian Ebling / sebastian.ebl...@telekom.de
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



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

[OAUTH-WG] review draft-ietf-oauth-native-apps-07

[Sebastian.Ebling]

Hi,

there is a typo in B.4. 
Search for "are are" and replace it with "are".

Best regards

Sebastian

-- 
Sebastian Ebling / sebastian.ebl...@telekom.de / +49 6151 5838207
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)

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