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

[William Denniss <[e-mail]>]

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 <[e-mail]> 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 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 <[e-mail]>
> wrote:
>
>> 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
>> <[e-mail]> 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 <
>> [e-mail]> wrote:
>> >>
>> >> 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
>> >>
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> [e-mail]
>> >> 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.
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>