Device Access Token Request requires POST authentication - does not work with basic auth

[zachmann]

When doing the device flow iam requires authentication by posting client id and client secret to the token endpoint when looking up the device code. However, this should work without posting client credentials, when I use basic authentication (and it is activated for that client). The device flow draft does not mention that posting client credentials is required. It says that normal authentication method registered for that client must be used.

Request data: client_id=<client_id>&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=<device_code> Basic authentication is used Response: {"error":"invalid_client","error_description":"Bad client credentials"}

However, when also posting the client_secret it works.

[andreaceccanti]

The device endpoint on IAM currently requires FORM authentication. So just dropping the basic authorization header should solve your issue.

[zachmann]

The Header does not have to be dropped. Form authentication works also with the header. However, I think it should also work with basic authentication and not require form authentication.

[andreaceccanti]

I got a bit confused. Are we talking about the token or the devicecode endpoint? The /devicecode endpoint actually requires basic authentication AFAIU. The /token endpoint supports both basic and form authentication depending on the client configuration. Which one are we talking about? Can you post the full request details that is giving you problems?

Thanks

[zachmann]

We're talking about the token endpoint in the context of the device flow. (Where the client polls for an access token using the device code, https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13#section-3.4).

Yes the token endpoint normally supports both authentication forms, depending on the client configuration. However, when doing this access token request as part of the device flow, only form authentication is accepted.

Consider the following curl call:

curl -X POST https://iam.deep-hybrid-datacloud.eu/token -p $CLIENT_ID:$CLIENT_SECRET -d "client_id=$CLIENT_ID&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=device_code"

However, if I add the client secret to the form data, it works.

curl -X POST https://iam.deep-hybrid-datacloud.eu/token -p $CLIENT_ID:$CLIENT_SECRET -d "client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=device_code"

But I think the token endpoint should accept basic auth in the header also for requests that are part of the device flow.

[andreaceccanti]

But I think the token endpoint should accept basic auth in the header also for requests that are part of the device flow.

if the client is configured to use basic auth for the token endpoint, yes, you're right! What happens if you drop the client_id parameter from the form? That's probably confusing IAM, so that it thinks that you're using form auth while in fact you're using basic auth. Could you check?

Thanks

[zachmann]

You'r right, that did fix the problem. (I thought that I did test it without success).

However, I'm not sure, if IAM should not just ignore that parameter (or still check the auth header). If it'd first check the auth header before checking the form that also shouldn't be problem.

[andreaceccanti]

The basic auth filter comes first, the form auth second. Ideally the form shouldn't mess with the basic auth, but in practice if you include client_id IAM thinks you're using form authentication and if you don't provide a secret things go wrong (even if there's the basic auth set).

It's true that IAM could be smarter and actually enforce what comes from the client configuration (i.e., a client configured to use basic auth shouldn't be capable of authenticating with form auth and viceversa).