[OAUTH-WG] OAuth Device Flow is now RFC 8628

[Mike Jones]

The OAuth Device Flow specification (recently renamed to be the OAuth 2.0 
Device Authorization Grant specification) is now RFC 
8628.  The abstract describes the 
specification as:

The OAuth 2.0 device authorization grant is designed for Internet-connected 
devices that either lack a browser to perform a user-agent-based authorization 
or are input constrained to the extent that requiring the user to input text in 
order to authenticate during the authorization flow is impractical.  It enables 
OAuth clients on such devices (like smart TVs, media consoles, digital picture 
frames, and printers) to obtain user authorization to access protected 
resources by using a user agent on a separate device.

This specification standardizes an already widely-deployed pattern in 
production use by Facebook, ForgeRock, Google, Microsoft, Salesforce, and many 
others.  Thanks to all of you who helped make this existing practice an actual 
standard!

   -- Mike

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

[OAUTH-WG] OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

[Mike Jones]

I made a blog post about the renaming of the device spec and last-minute 
clarifications applied at http://self-issued.info/?p=1959 and 
@selfissued.  Thanks again to William for doing 
the heavy lifting!

Hopefully this is the version that gets sent to the RFC Editor…

  -- Mike

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

[OAUTH-WG] OAuth Device Flow spec addressing initial IETF last call feedback

[Mike Jones]

The OAuth Device Flow specification (full name "OAuth 2.0 Device Flow for 
Browserless and Input Constrained Devices") has been updated to address 
comments received to date from the IETF last call.  Thanks to William 
Denniss
 for taking the pen for this set of revisions.  Changes were:

  *   Added a missing definition of access_denied for use on the token endpoint.
  *   Corrected text documenting which error code should be returned for 
expired tokens (it's "expired_token", not "invalid_grant").
  *   Corrected section reference to RFC 8252 (the section numbers had changed 
after the initial reference was made).
  *   Fixed line length of one diagram (was causing xml2rfc warnings).
  *   Added line breaks so the URN grant_type is presented on an unbroken line.
  *   Typos fixed and other stylistic improvements.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-oauth-device-flow-10.html

   -- Mike

P.S.  This notice was also published at http://self-issued.info/?p=1873 and as 
@selfissued.

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

[OAUTH-WG] OAuth Device Flow spec addressing Area Director comments

[Mike Jones]

The OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 
specification has been updated to address feedback by Security Area Director 
Eric Rescorla about the potential of a confused deputy attack.  Thanks to John 
Bradley for helping work out the response to Eric 
and to William Denniss for reviewing and 
publishing the changes to the draft.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-oauth-device-flow-09.html

-- Mike

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

Re: [OAUTH-WG] OAuth Device Flow data from Microsoft implementations

[Alex Bilbie]

Hi Mike,

Some interesting feedback.


> One of the two implementations has an optional “message” parameter
> containing text that is to be shown to the user.  This one also uses a
> “mkt” parameter to indicate the locale of the message (as opposed to, for
> instance, ui_locales).  The developers want to know what the working group
> thinks of the possibility of supporting some kind of a “message” parameter.


In our test implementation we're serving a localised message parameter by
interpreting the Accept-Language request header.

I agree that an optional message parameter should be part of the
specification.

Alex

On Sun, 8 May 2016 at 06:27 Mike Jones  wrote:

> I sat down with the two Microsoft teams that have implementations of the
> OAuth Device Flow and compared what they currently have built to
> draft-ietf-oauth-device-flow.  Here’s some data that we assembled…
>
>
>
> One of the two implementations has an optional “message” parameter
> containing text that is to be shown to the user.  This one also uses a
> “mkt” parameter to indicate the locale of the message (as opposed to, for
> instance, ui_locales).  The developers want to know what the working group
> thinks of the possibility of supporting some kind of a “message” parameter.
>
>
>
> The developers would like an example in the spec that shows the use of
> simple polling.
>
>
>
> We are using the “device_code” grant type.  The token request is missing
> from the spec, including the grant type being missing from the spec.
>
>
>
> One implementation adds two new errors: auth_pending and
> expired_device_code.  (The spec uses authorization_pending.)  This
> implementation also uses the access_denied error defined by RFC 6749.
>
>
>
> The other uses authorization_pending, code_expired, and
> authorization_declined.  The developers agreed that authorization_declined
> should become access_denied.  That implementation hasn’t implemented
> slow_down.
>
>
>
> The developers wanted to ask what the right code expiration error code
> is.  They felt that invalid_grant may be a bit too broad.
>
>
>
> Our requests in both implementations do match the specification.
>
>
>
> Our implementations currently use verification_url instead of
> verification_uri.  This should be changed to verification_uri to match IETF
> naming practices.
>
>
>
> Our default expires_in is 900 (15 minutes).  Our default interval is 5
> seconds.
>
>
>
> Both implementations do intend to migrate to the syntax in the eventual
> final specification.
>
>
>
>   -- Mike
>
>
>
>
>
>
> ___
> 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] OAuth Device Flow data from Microsoft implementations

[Mike Jones]

I sat down with the two Microsoft teams that have implementations of the OAuth 
Device Flow and compared what they currently have built to 
draft-ietf-oauth-device-flow.  Here's some data that we assembled...

One of the two implementations has an optional "message" parameter containing 
text that is to be shown to the user.  This one also uses a "mkt" parameter to 
indicate the locale of the message (as opposed to, for instance, ui_locales).  
The developers want to know what the working group thinks of the possibility of 
supporting some kind of a "message" parameter.

The developers would like an example in the spec that shows the use of simple 
polling.

We are using the "device_code" grant type.  The token request is missing from 
the spec, including the grant type being missing from the spec.

One implementation adds two new errors: auth_pending and expired_device_code.  
(The spec uses authorization_pending.)  This implementation also uses the 
access_denied error defined by RFC 6749.

The other uses authorization_pending, code_expired, and authorization_declined. 
 The developers agreed that authorization_declined should become access_denied. 
 That implementation hasn't implemented slow_down.

The developers wanted to ask what the right code expiration error code is.  
They felt that invalid_grant may be a bit too broad.

Our requests in both implementations do match the specification.

Our implementations currently use verification_url instead of verification_uri. 
 This should be changed to verification_uri to match IETF naming practices.

Our default expires_in is 900 (15 minutes).  Our default interval is 5 seconds.

Both implementations do intend to migrate to the syntax in the eventual final 
specification.

  -- Mike



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

Re: [OAUTH-WG] OAuth Device Flow

[Aaron Parecki]

In reading this over, I noticed a subtle difference from the Facebook and
Google implementations, and I'm wondering if this was intentional or not.

Section 3.1 says "The authorization server prompts the end-user to
authorize the client's request by entering the end-user code provided by
the client." The introduction has even more explicitly different wording:
"(D) ... If the end-user agrees to the client's access request, the
end-user enters the end-user code provided by the client."

However this is different from Facebook and Google's implementations, which
work as follows:

   - Device shows the verification URI and code to the user
   - The user visits the URL and is prompted to sign in to the service
   (Google has the extra step of then choosing which Youtube account to use)
   - The user is then prompted to enter the device code
   - After entering the device code, the authorization prompt is displayed

In reading this draft, the implication is that the act of entering the code
also is the authorization. The problem is that the server won't know things
like the scope or application name until after the code is entered, so it
can't properly show an authorization prompt.

I think this needs to be reworded to separate entering the code from
showing the authorization prompt. I believe it is only a wording change.
Maybe something more like:

3.1 "The authorization server prompts the end-user to enter the end-user
code provided by the client, after which it prompts the end-user to
authorize the client's request."

and in the introduction:

1. (D) "The authorization server authenticates the end-user (via the
user-agent) and prompts the end-user to enter the end-user code provided by
the client. The authorization server validates the end-user code and
prompts the end-user to grant the client's access request."


Aaron Parecki
aaronparecki.com
@aaronpk 


On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig  wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
> Here is the document:
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
>
> Here are two deployment examples that are reasonably well described:
>
> - Google
> https://developers.google.com/youtube/v3/guides/auth/devices
>
> - Facebook
> https://developers.facebook.com/docs/facebook-login/for-devices
>
> Ciao
> Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Device Flow

[Aaron Parecki]

I just noticed a typo, section 3.2 should refer to RFC6749 section 4.1.3
instead of 4.1.1

https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00#section-3.2

Section 4.1.1 is the authorization request, 4.1.3 is the access token
request which I believe is what's supposed to be referenced.


Aaron Parecki
aaronparecki.com
@aaronpk 


On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig  wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
> Here is the document:
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
>
> Here are two deployment examples that are reasonably well described:
>
> - Google
> https://developers.google.com/youtube/v3/guides/auth/devices
>
> - Facebook
> https://developers.facebook.com/docs/facebook-login/for-devices
>
> Ciao
> Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Device Flow

[Hannes Tschofenig]

FYI: A couple of us got together and re-published an old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3/guides/auth/devices

- Facebook
https://developers.facebook.com/docs/facebook-login/for-devices

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Device Flow

[William Denniss]

Google has additional documentation here:
https://developers.google.com/identity/protocols/OAuth2ForDevices

The implementation mostly follows the original draft, but there are a few
differences. Also we've learnt a lot about the security and usability
implications of this flow along the way, which would be good to document.

On Thu, Nov 5, 2015 at 9:44 AM, Hannes Tschofenig  wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
> Here is the document:
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
>
> Here are two deployment examples that are reasonably well described:
>
> - Google
> https://developers.google.com/youtube/v3/guides/auth/devices
>
> - Facebook
> https://developers.facebook.com/docs/facebook-login/for-devices
>
> Ciao
> Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth