'Bad client credentials' from IdP when using client secret

[willfurnell]

Hi,

I'm having some trouble getting this working when using a non-public client (making the client public makes it work fine, which suggests this might be some sort of auth error?). My config on the client and server side is as follows, am I doing anything obviously wrong please? Thanks!

{
    "oauth": {
        "client": {
            "id": "a-client-id-redacted",
            "secret": "a-client-secret-redacted"
        },
        "scope": "openid profile email offline_access",
        "device_endpoint":"https://iris-iam.stfc.ac.uk/devicecode",
        "token_endpoint": "https://iris-iam.stfc.ac.uk/token",
        "userinfo_endpoint": "https://iris-iam.stfc.ac.uk/userinfo",
        "username_attribute": "email"
    },
    "qr": {
        "error_correction_level": 0
    },
    "users": {
        "email@example.ac.uk": [
            "root"
        ]
    }
}

I've tried all Token Endpoint Authentication Methods without success.

[tauceti2]

Hi Will,

on the first sight the configuration looks OK. Can you explain little bit more what do you mean by non-public and public client? Having public IP? Can you share also the error message?

Michal P.

[willfurnell]

Sorry, by public client I mean one that does not have any client secret - no authentication effectively. Like you'd use for a single page web app.

The error message I'm getting from the IdP is {"error":"invalid_client","error_description":"Bad client credentials"}

[tauceti2]

Sorry for the delay, I was on vacations. Are you sure you have client secret and client id same on both client and server (no white spaces etc.)?

[willfurnell]

So I've figured out that this is partly a bug on the IAM side (and possibly this client side too).

https://github.com/indigo-iam/iam/issues/277

When doing the CURL call in poll_for_token, &client_id= is appended to the parameters, even though we are doing Basic Authentication. It looks like the IAM sees this, and then expects Form Authentication, which then won't work. By removing that parameter from the CURL call, everything seems to work fine with a client ID and secret!