[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

[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

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
https://www.ietf.org/mailman/listinfo/oauth