[OAUTH-WG] Device flow clarifications

[Alex Bilbie]

N.B: I sent the following email to
draft-ietf-oauth-device-***@tools.ietf.org on 12th April but didn't
receive a reply so am reposting here:

---

Hello,

I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01).

Please could the following points please be clarified:

Section 3.2: "The client requests an access token by making an HTTP "POST"
request to the token endpoint as described in Section 4.1.1 of [RFC6749]"

Should this actually say Section 4.1.3 of RFC6749 which is the Access Token
Request section for the authorisation code grant?

Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?

Many thanks,

Alex Bilbie

[Oli Dagenais]

Hi Alex,

I’m also working on an implementation based on the draft specification. I came to the same conclusion about linking to Section 4.1.3 of RFC6749.

As for your second question, I also came to the same conclusion, which was confirmed by looking at the source code to the Active Directory Authentication Library (ADAL) for .NET (Azure Active Directory is my project’s first target). ADAL also sets the grant_type parameter to “device_code” (contrast this with the value originally in section 4.1.3).

I am hoping to also test my implementation against other major server implementations (Google and Facebook come to mind) in the next few weeks and will report my findings to this mailing list.

Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Alex Bilbie
Sent: Friday, April 15, 2016 13:32
To: ***@ietf.org
Subject: [OAUTH-WG] Device flow clarifications

N.B: I sent the following email to draft-ietf-oauth-device-***@tools.ietf.org<mailto:draft-ietf-oauth-device-***@tools.ietf.org> on 12th April but didn't receive a reply so am reposting here:

---

Hello,

I've been working on an implementation of the OAuth 2.0 Device Flow (as described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>).

Please could the following points please be clarified:

Section 3.2: "The client requests an access token by making an HTTP "POST" request to the token endpoint as described in Section 4.1.1 of [RFC6749]"

Should this actually say Section 4.1.3 of RFC6749 which is the Access Token Request section for the authorisation code grant?

Assuming the above is true, should the `code` parameter POSTed to the authorisation server be the value of the `device_code` parameter returned to the client in the initiating request?

Many thanks,

Alex Bilbie

[Aaron Parecki]

Hi Alex and Oli,

I also believe you are correct. I posted a similar question a while ago
here:

https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html

I had a couple other notes you may be interested in:

https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html

My implementation of a server that implements the device flow is here,
although it actually acts as a proxy for existing OAuth services:

https://github.com/aaronpk/TVAuthServer

Cheers!

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft specification. I
came to the same conclusion about linking to Section 4.1.3 of RFC6749.
As for your second question, I also came to the same conclusion, which was
confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP "POST"
request to the token endpoint as described in Section 4.1.1 of [RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[William Denniss]

I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified

I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>.

I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft specification. I
came to the same conclusion about linking to Section 4.1.3 of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

I hate to be pedantic but... well, here goes.

Grant types other than those defined in RFC 6749 are supposed to be URIs
(see section 4.5 on Extension Grants
<https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry
for grant_type values so name collisions are avoided via the use of URIs.

An IETF document like the Device Flow should probably use a stable IETF URI
rather than something under oauth.net, which it has no real relationship
with or control of. RFC 6755 <https://tools.ietf.org/html/rfc6755> exists
specifically for the purpose of obtaining/registering such URIs and even
has an example registration request
<https://tools.ietf.org/html/rfc6755#section-2.1> for a grant type URI.

Post by William Denniss
I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified
I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>.
I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft specification.
I came to the same conclusion about linking to Section 4.1.3 of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

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

[Aaron Parecki]

If you'd like to put up a web page at the
http://oauth.net/grant_type/device/1.0 URI that Google is using, feel free
to create it and send me a PR. I think it could be useful for developers if
there is a minimal page there that talks about the device flow.

<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>https://github.com/aaronpk/oauth.net

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Brian Campbell
I hate to be pedantic but... well, here goes.
Grant types other than those defined in RFC 6749 are supposed to be URIs
(see section 4.5 on Extension Grants
<https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry
for grant_type values so name collisions are avoided via the use of URIs.
An IETF document like the Device Flow should probably use a stable IETF
URI rather than something under oauth.net, which it has no real
relationship with or control of. RFC 6755
<https://tools.ietf.org/html/rfc6755> exists specifically for the purpose
of obtaining/registering such URIs and even has an example registration
request <https://tools.ietf.org/html/rfc6755#section-2.1> for a grant
type URI.

Post by William Denniss
I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified
I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>
.
I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft specification.
I came to the same conclusion about linking to Section 4.1.3 of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

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

[William Denniss]

Post by Aaron Parecki
If you'd like to put up a web page at the
http://oauth.net/grant_type/device/1.0 URI that Google is using, feel
free to create it and send me a PR. I think it could be useful for
developers if there is a minimal page there that talks about the device
flow.
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>https://github.com/aaronpk/oauth.net

Good idea, thanks! https://github.com/aaronpk/oauth.net/pull/125

Post by Aaron Parecki
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Brian Campbell
I hate to be pedantic but... well, here goes.
Grant types other than those defined in RFC 6749 are supposed to be URIs
(see section 4.5 on Extension Grants
<https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry
for grant_type values so name collisions are avoided via the use of URIs.
An IETF document like the Device Flow should probably use a stable IETF
URI rather than something under oauth.net, which it has no real
relationship with or control of. RFC 6755
<https://tools.ietf.org/html/rfc6755> exists specifically for the
purpose of obtaining/registering such URIs and even has an example
registration request <https://tools.ietf.org/html/rfc6755#section-2.1>
for a grant type URI.

Post by William Denniss
I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified
I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>
.
I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft
specification. I came to the same conclusion about linking to Section 4.1.3
of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow
(as described at
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

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

[William Denniss]

Post by Brian Campbell
I hate to be pedantic but... well, here goes.

Thanks for your review, it's important to get this right :-)

Post by Brian Campbell
Grant types other than those defined in RFC 6749 are supposed to be URIs
(see section 4.5 on Extension Grants
<https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry
for grant_type values so name collisions are avoided via the use of URIs.

Glad you pointed this out. I had assumed there was a registry for
base-level strings, and only non-standard extensions would need a URI, but
you're right.

Post by Brian Campbell
An IETF document like the Device Flow should probably use a stable IETF
URI rather than something under oauth.net, which it has no real
relationship with or control of.

I agree, it was never my proposal to use that, I was just pointing out that
our current implementation does. My plan would be to release a new version
of our endpoint once the spec is near-final, to conform to the standard.

Post by Brian Campbell
RFC 6755 <https://tools.ietf.org/html/rfc6755> exists specifically for
the purpose of obtaining/registering such URIs and even has an example
registration request <https://tools.ietf.org/html/rfc6755#section-2.1>
for a grant type URI.

That example is useful. So what do people think about standardizing on:

*urn:ietf:params:oauth:grant-type:device_code*

Post by Brian Campbell

Post by William Denniss
I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified
I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>
.
I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft specification.
I came to the same conclusion about linking to Section 4.1.3 of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

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

[Brian Campbell]

Post by William Denniss

Post by Brian Campbell
I hate to be pedantic but... well, here goes.

Thanks for your review, it's important to get this right :-)

Well, I haven't actually reviewed the draft yet. But I will. I just noticed
the email thread. 6755 was my first RFC so I'm kind of partial to it
getting used :)

Post by William Denniss

Post by Brian Campbell
Grant types other than those defined in RFC 6749 are supposed to be URIs
(see section 4.5 on Extension Grants
<https://tools.ietf.org/html/rfc6749#section-4.5>). There's no registry
for grant_type values so name collisions are avoided via the use of URIs.

Glad you pointed this out. I had assumed there was a registry for
base-level strings, and only non-standard extensions would need a URI, but
you're right.

That probably would have been a better way for 6749 to have set things up
but that's water under the bridge at this point.

Post by William Denniss

Post by Brian Campbell
An IETF document like the Device Flow should probably use a stable IETF
URI rather than something under oauth.net, which it has no real
relationship with or control of.

I agree, it was never my proposal to use that, I was just pointing out
that our current implementation does.

I figured. I was just looking to head-off the potential suggesting coming
from elsewhere.

Post by William Denniss
My plan would be to release a new version of our endpoint once the spec is
near-final, to conform to the standard.

Excellent.

Post by William Denniss

Post by Brian Campbell
RFC 6755 <https://tools.ietf.org/html/rfc6755> exists specifically for
the purpose of obtaining/registering such URIs and even has an example
registration request <https://tools.ietf.org/html/rfc6755#section-2.1>
for a grant type URI.

*urn:ietf:params:oauth:grant-type:device_code*

Works for me.

Post by William Denniss

Post by Brian Campbell

Post by William Denniss
I agree that the token request section was not well defined, using the
OAuth 2.0 definition in this case isn't correct as there are unique aspects
of the Device Flow grant_type that need to be specified
I've posted an update that fleshes out the token request polling &
response. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02
Section 3.2 referenced in the above email is now numbered 3.4
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-02#section-3.4>
.
I specified a grant_type value of "device_code" as it matches the
convention for other OAuth grant types. Google's implementation
<https://developers.google.com/identity/protocols/OAuth2ForDevices#obtainingatoken>
currently uses a URI instead: http://oauth.net/grant_type/device/1.0.

Post by Aaron Parecki
Hi Alex and Oli,
I also believe you are correct. I posted a similar question a while ago
https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html
https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html
My implementation of a server that implements the device flow is here,
https://github.com/aaronpk/TVAuthServer
Cheers!
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Oli Dagenais
Hi Alex,
I’m also working on an implementation based on the draft
specification. I came to the same conclusion about linking to Section 4.1.3
of RFC6749.
As for your second question, I also came to the same conclusion, which
was confirmed by looking at the source code to the Active Directory
Authentication Library (ADAL) for .NET (Azure Active Directory is my
project’s first target). ADAL also sets the grant_type parameter to
“device_code” (contrast this with the value originally in section 4.1.3).
I am hoping to also test my implementation against other major server
implementations (Google and Facebook come to mind) in the next few weeks
and will report my findings to this mailing list.
Cheers,
- Oli
--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
[phone]
*Sent:* Friday, April 15, 2016 13:32
*Subject:* [OAUTH-WG] Device flow clarifications
N.B: I sent the following email to
---
Hello,
I've been working on an implementation of the OAuth 2.0 Device Flow
(as described at
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-device-flow-01&data=01%7c01%7colivida%40microsoft.com%7c1cf0164e15984b96d6ad08d36553de5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Aw6hIdrAeX5%2feexlbPdZZiOYNdD6ETBP2bwnVpAuBIY%3d>
).
Section 3.2: "The client requests an access token by making an HTTP
"POST" request to the token endpoint as described in Section 4.1.1 of
[RFC6749]"
Should this actually say Section 4.1.3 of RFC6749 which is the Access
Token Request section for the authorisation code grant?
Assuming the above is true, should the `code` parameter POSTed to the
authorisation server be the value of the `device_code` parameter returned
to the client in the initiating request?
Many thanks,
Alex Bilbie
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

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