Subject: [OAUTH-WG] OAuth 2.0 Device flow error response

From: Emond Papegaaij <[email-masked]>
Date: Fri, 08 Mar 2019 13:22:36 +0100

Dear all,

I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless 
and Input Constrained Devices and noticed a possible omission in the spec. 
Section 3.2 describes the Device Authorization Response, but only the success 
response is specified, not the error response. I would have expected a 
standard OAuth 2.0 error response, probably with the following error codes: 
invalid_request, invalid_client and invalid_scope.

Best regards,
Emond Papegaaij
Topicus KeyHub

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Mar 2019 14:24:17 -0700

While probably not terribly important from an interoperability perspective,
I agree that does seem like an omission.

I took a quick look at our implementation and bad requests to the device
authorization endpoint will indeed return what is a standard OAuth 2.0
error response normally from the token endpoint with invalid_client or
invalid_scope error codes. And a little bit of poking at Google's device
authorization endpoint suggests it behaves similarly. I suspect it's pretty
typical.

On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Emond Papegaaij <[email-masked]>
Date: Mon, 11 Mar 2019 15:01:19 +0100

Yes, that's how I implemented it as well. I return 'invalid_request'
when the client_id is missing entirely.

Do you have any thoughts how this specification should work in
combination with other specs, such as OIDC? For example, the OIDC
Authentication Request specifies several additional parameters, some
of which may be applicable for the device flow as well. Can the device
flow be used to obtain an ID token? How should parameters like
'max_age', 'id_token_hint' and 'claims' be processed? My plan was to
construct a pseudo-authentication/authorization request using the
parameters specified at the device authorization endpoint and apply
these parameters during the user interaction. Some parameters, such as
'prompt=3Dnone', do not make much sense though.

I think it may be a good idea to describe how this spec is supposed to
interoperate with other specifications, especially those that extend
the Authorization Endpoint. This definition can never be complete, as
new specs will be defined after this one, but it can at least try to
describe the general rules that apply.

PS. Other specifications also define additional parameters that may be
useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and
'include_granted_scopes' from OAuth 2.0 Incremental Authorization.

Best regards,
Emond Papegaaij
Topicus KeyHub

On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
<[email-masked]> wrote:
>
> While probably not terribly important from an interoperability perspective, I agree that does seem like an omission.
>
> I took a quick look at our implementation and bad requests to the device authorization endpoint will indeed return what is a standard OAuth 2.0 error response normally from the token endpoint with invalid_client or invalid_scope error codes. And a little bit of poking at Google's device authorization endpoint suggests it behaves similarly. I suspect it's pretty typical.
>
>
>
> On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <[email-masked]> wrote:
>>
>> Dear all,
>>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Filip Skokan <[email-masked]>
Date: Mon, 11 Mar 2019 18:28:57 +0100

Hi Emond,

the way i approached implementation of device flow into an OIDC server was
to allow all already registered and handled parameters excluding the ones
[1] that really don't make sense for the flow at the device authorization
endpoint.

What can be validated at the device authorization endpoint time is,
everything else runs as part of the regular authorization pipeline for
which i also construct the request based on the params saved together with
the device code backend model. Everything else that depends on the actual
device where authnz happens is processed as part of the web request
following the user code submission. When errors occur that cannot be
resolved with user interaction the error is assigned to the device code and
returned to the device with the next poll. I did not exclude prompt:none,
as the pipeline processing starts after the submission it's possible that
no prompt will occur there, but i can see how it may be weird. Yes the
result at the token endpoint will include an id token if the scope included
`openid` as one would expect, just like it will include a refresh token if
`offline_access` is present. `resource` specifically is available as per
the resource indicator spec at device authorization as well as token
endpoints.

I guess this is very similar to what you're thinking.

I don't think we need to (and can for that matter) enumerate all possible
OAuth2.0 extensions in the specification.

[1] web_message_uri, web_message_target, response_type, response_mode,
state, redirect_uri

S pozdravem,
*Filip Skokan*

On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij <[email-masked]>
wrote:

> > While probably not terribly important from an interoperability
> perspective, I agree that does seem like an omission.
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.
>

---

From: William Denniss <[email-masked]>
Date: Mon, 11 Mar 2019 14:15:05 -0700

Good catch. To the "Device Authorization Response" section I will add:

    In the event of an error (such as an invalidly configured client),
    the authorization server responds in the same way as the token endpoint
    specified in Section 5.2 of RFC 6749.

On Mon, Mar 11, 2019 at 10:30 AM Filip Skokan <[email-masked]> wrote:

> no prompt will occur there, but i can see how it may be weird.. Yes the
>> > I took a quick look at our implementation and bad requests to the
>> device authorization endpoint will indeed return what is a standard OAuth
>> 2.0 error response normally from the token endpoint with invalid_client or

---

From: Emond Papegaaij <[email-masked]>
Date: Mon, 11 Mar 2019 22:34:07 +0100

Hi Filip,

Yes, this was exactly what I was thinking about. Good to know I'm
working in the right direction. I must say that the spec reads really
well and is fairly straightforward to implement.

Best regards,
Emond Papegaaij
Topicus KeyHub

On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan <[email-masked]> wrote:
>
> Hi Emond,
>
> the way i approached implementation of device flow into an OIDC server was to allow all already registered and handled parameters excluding the ones [1] that really don't make sense for the flow at the device authorization endpoint.
>
> What can be validated at the device authorization endpoint time is, everything else runs as part of the regular authorization pipeline for which i also construct the request based on the params saved together with the device code backend model. Everything else that depends on the actual device where authnz happens is processed as part of the web request following the user code submission. When errors occur that cannot be resolved with user interaction the error is assigned to the device code and returned to the device with the next poll. I did not exclude prompt:none, as the pipeline processing starts after the submission it's possible that no prompt will occur there, but i can see how it may be weird. Yes the result at the token endpoint will include an id token if the scope included `openid` as one would expect, just like it will include a refresh token if `offline_access` is present. `resource` specifically is available as per the resource indicator spec at device authorization as well as token endpoints.
>
> I don't think we need to (and can for that matter) enumerate all possible OAuth2.0 extensions in the specification.
>
> [1] web_message_uri, web_message_target, response_type, response_mode, state, redirect_uri
>
> S pozdravem,
> Filip Skokan
>
>
> On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij <[email-masked]> wrote:
>>