Hi All,

Reading through Leo's recently posted blog: OAuth: Device Flows - IBM Security Identity and Access

IBM Security Identity and Access		remove preview
OAuth: Device Flows - IBM Security Identity and Access OAuth: Device Flows Introduction to Device Flows As IOT devices become more prevalent, so does the importance of the way these devices interact with user information and the web. These devices often need to call APIs which require authentication, but cannot provide a suitable method of user interaction in order for traditional authentication mechanisms such as username/password. View this on IBM Security Identity and Access >

I've had quiet a bit of difficulty getting up and running with the device flow.

After following his article, I noticed that he posted an issue where the issued tokens had a lifetime of 0, exactly the issue I was hitting, so I put the code into my PostTokenGeneration mapping rule.

Yet, didn't resolve the issue, strangely enough, after some more debugging I inspected the JavaDoc:

public static boolean updateToken(java.lang.String tokenId,
                                  java.lang.Long newLifetime,
                                  java.lang.Long newLastUsed,
                                  java.lang.Boolean enabled)

Parameters:

tokenId - identifier of the token to update. Cannot be null.

newLifetime - the new lifetime of the token in milliseconds. If null the lifetime will not be changed.

newLastUsed - the new date last used of the token in milliseconds. If null the date last used will not be changed.

enabled - whether or not the token is enabled.

There's this parameter "enabled", where in Leo's code it's set to "false", thus never activating the issued tokens and would always return false on introspect.

Anyway, changing invoke to:
var updated = OAuthMappingExtUtils.updateToken(t.getId(), lifetime,null,true);

Solved the issue, and my tokens are now valid, introspection returns useful results and can be used for other calls.

Hope this helps out anyone looking into this as well, and for it to be correct in the blog post as well, which will save you a headache.

------------------------------
Kind regards,

Dries Eestermans
IS4U
------------------------------

Hi Dries,

I've updated the article. It should replicate shortly. 

Thanks you for letting me know. 

------------------------------
Leo Farrell
------------------------------

Hi Leo,

Thanks for the reply, the blog was a nice read!

Anyway, I'm not sure if it's my setup or still an issue with the new flow, but it appears my requested scopes are not displayed on the user_authorize page?
So I perform the request:
POST /mga/sps/oauth/oauth20/device_authorize HTTP/1.1
Host: domain.xyz
Content-Type: application/x-www-form-urlencoded
Accept: application/json

client_id=eLa6UXp155rxFUixqvZ2&scope=openid

Navigate to the returned verification_uri_complete, and notice the following:


Whereas, with a regular Authorization Code flow, I receive the following:
GET /mga/sps/oauth/oauth20/authorize?scope=openid profile xyz&response_type=code&client_id=oM9kGpPNrCe4xTbX2lFG&redirect_uri=http://deadend.local&state=xyz HTTP/1.1
Host: domain.xyz


Is there a way to persist this? The only way I can display the scope is by manually appending it as a query parameter:

Another issue I'm having is when I deny the authorization request:

It seems to display the "error": "access_denied" (as defined by https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-3.5) in my browser, instead of for my client's backchannel requests.
Upon denying, my client receives:
{
"error_description": "FBTOAU256E Pending. The user code is not yet verified.",
"error": "authorization_pending"
}

Up until the point of where the device code expires:
{
"error_description": "FBTOAU211E The [authorization_grant] received of type [urn:ietf:params:oauth:grant-type:device_code] does not exist.",
"error": "invalid_token"
}

Whereas I would expect an immediate "access_denied The end-user denied the authorization request." error.

Thanks for noticing.

------------------------------
Kind regards,

Dries Eestermans
IS4U
------------------------------

Original Message:
Sent: 07-13-2018 02:15
From: Leo Farrell
Subject: OAuth: Device Flows

Hi Dries,

I've updated the article. It should replicate shortly.

Thanks you for letting me know. 

------------------------------
Leo Farrell
------------------------------

Hi Dries,

Thanks for the feedback. I've got an action open to look into these and address appropriately.

If you need a fix for these  feel free to open a case and provide the case number here from there I can follow it up with the support team. 

Thanks

------------------------------
Leo Farrell
------------------------------

Original Message:
Sent: 07-14-2018 11:05
From: Dries Eestermans
Subject: OAuth: Device Flows

Hi Leo,

Thanks for the reply, the blog was a nice read!

Anyway, I'm not sure if it's my setup or still an issue with the new flow, but it appears my requested scopes are not displayed on the user_authorize page?
So I perform the request:
POST /mga/sps/oauth/oauth20/device_authorize HTTP/1.1
Host: domain.xyz
Content-Type: application/x-www-form-urlencoded
Accept: application/json

client_id=eLa6UXp155rxFUixqvZ2&scope=openid

Navigate to the returned verification_uri_complete, and notice the following:


Whereas, with a regular Authorization Code flow, I receive the following:
GET /mga/sps/oauth/oauth20/authorize?scope=openid profile xyz&response_type=code&client_id=oM9kGpPNrCe4xTbX2lFG&redirect_uri=http://deadend.local&state=xyz HTTP/1.1
Host: domain.xyz


Is there a way to persist this? The only way I can display the scope is by manually appending it as a query parameter:

Another issue I'm having is when I deny the authorization request:

It seems to display the "error": "access_denied" (as defined by https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-3.5) in my browser, instead of for my client's backchannel requests.
Upon denying, my client receives:
{
"error_description": "FBTOAU256E Pending. The user code is not yet verified.",
"error": "authorization_pending"
}

Up until the point of where the device code expires:
{
"error_description": "FBTOAU211E The [authorization_grant] received of type [urn:ietf:params:oauth:grant-type:device_code] does not exist.",
"error": "invalid_token"
}

Whereas I would expect an immediate "access_denied The end-user denied the authorization request." error.

Thanks for noticing.

------------------------------
Kind regards,

Dries Eestermans
IS4U
------------------------------


Original Message:
Sent: 07-13-2018 02:15
From: Leo Farrell
Subject: OAuth: Device Flows

Hi Dries,

I've updated the article. It should replicate shortly.

Thanks you for letting me know. 

------------------------------
Leo Farrell

Hi Leo,

PMRs were converted to cases, please find case numbers below:
TS001201300
TS001201301

If you need any additional information regarding my setup, kindly let me know via the case.

------------------------------
Kind regards,

Dries Eestermans
IS4U
------------------------------

Original Message:
Sent: 07-25-2018 03:33
From: Leo Farrell
Subject: OAuth: Device Flows

Hi Dries,

Thanks for the feedback. I've got an action open to look into these and address appropriately.

If you need a fix for these  feel free to open a case and provide the case number here from there I can follow it up with the support team.

Thanks

------------------------------
Leo Farrell
------------------------------


Original Message:
Sent: 07-14-2018 11:05
From: Dries Eestermans
Subject: OAuth: Device Flows

Hi Leo,

Thanks for the reply, the blog was a nice read!

Anyway, I'm not sure if it's my setup or still an issue with the new flow, but it appears my requested scopes are not displayed on the user_authorize page?
So I perform the request:
POST /mga/sps/oauth/oauth20/device_authorize HTTP/1.1
Host: domain.xyz
Content-Type: application/x-www-form-urlencoded
Accept: application/json

client_id=eLa6UXp155rxFUixqvZ2&scope=openid

Navigate to the returned verification_uri_complete, and notice the following:


Whereas, with a regular Authorization Code flow, I receive the following:
GET /mga/sps/oauth/oauth20/authorize?scope=openid profile xyz&response_type=code&client_id=oM9kGpPNrCe4xTbX2lFG&redirect_uri=http://deadend.local&state=xyz HTTP/1.1
Host: domain.xyz


Is there a way to persist this? The only way I can display the scope is by manually appending it as a query parameter:

Another issue I'm having is when I deny the authorization request:

It seems to display the "error": "access_denied" (as defined by https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-3.5) in my browser, instead of for my client's backchannel requests.
Upon denying, my client receives:
{
"error_description": "FBTOAU256E Pending. The user code is not yet verified.",
"error": "authorization_pending"
}

Up until the point of where the device code expires:
{
"error_description": "FBTOAU211E The [authorization_grant] received of type [urn:ietf:params:oauth:grant-type:device_code] does not exist.",
"error": "invalid_token"
}

Whereas I would expect an immediate "access_denied The end-user denied the authorization request." error.

Thanks for noticing.

------------------------------
Kind regards,

Dries Eestermans
IS4U


Original Message:
Sent: 07-13-2018 02:15
From: Leo Farrell
Subject: OAuth: Device Flows

Hi Dries,

I've updated the article. It should replicate shortly.

Thanks you for letting me know. 

------------------------------
Leo Farrell