Solved

OIDC silent login failure

  • 1 November 2022
  • 6 replies
  • 269 views

Hello, I'm working on setting up OIDC for our gd.cn instance.

Unfortunately it isn't working but I can't debug the issue from the GD side.

Here is the organization configuration:

{

    "data": {

    "id": "<myorgid>",

    "type": "organization",

    "attributes": {

        "name": "WizeHive",

        "hostname": "wizehive.poc.cloud.gooddata.com",

        "oauthIssuerLocation": "https://<ourhost.org>/",

        "oauthClientId": "jQPiFIaePpt5EQDav00zha_XvPmku2-SltwKcy79-tk",

        "oauthClientSecret": "<secret>"

    }

    }

}

Much of the login process appears to succeed. 

Here is a summary of the requests to the OIDC provider:

GET /.well-known/openid-configuration
200 - OK

GET /oauth/authorize?response_type=code&client_id=jQPiFIaePpt5EQDav00zha_XvPmku2-SltwKcy79-tk&scope=openid%20profile&state=RorYXYYc2SsLpFW1w-h9-gjYPQvNxoRRb6Fh6hsjGQY%3D&redirect_uri=https%3A%2F%2Fwizehive.poc.cloud.gooddata.com%2Flogin%2Foauth2%2Fcode%2Fwizehive.poc.cloud.gooddata.com&nonce=M6P7mmX2vPmJvoSdUt-iZHQfsUgE8hTVIYDPCWPHKeQ
200 - OK

POST /oauth/authorize
302
post body:
authenticity_token=h16hDa8G8ejOzHLaMutOVU07TXxHnTsWebO%2B0lKPryviT%2Bn%2BK%2By8RzgG2lrm3%2BrDRKJTiEbt6%2BD8hf8RShymYA%3D%3D&client_id=jQPiFIaePpt5EQDav00zha_XvPmku2-SltwKcy79-tk&redirect_uri=https%3A%2F%2Fwizehive.poc.cloud.gooddata.com%2Flogin%2Foauth2%2Fcode%2Fwizehive.poc.cloud.gooddata.com&state=RorYXYYc2SsLpFW1w-h9-gjYPQvNxoRRb6Fh6hsjGQY%3D&response_type=code&response_mode=query&scope=openid+profile&code_challenge=&code_challenge_method=&commit=Authorize
302 Location
https://wizehive.poc.cloud.gooddata.com/login/oauth2/code/wizehive.poc.cloud.gooddata.com?code=hi_A-NiwDXM7KNJ8usj2jPIkZWuW4EEdDIvIY18nyUc&state=RorYXYYc2SsLpFW1w-h9-gjYPQvNxoRRb6Fh6hsjGQY%3D

GET /.well-known/openid-configuration
200 - OK

POST /oauth/token
200 - OK
Posted token:
{

  "access_token": "2EVEak5k67gTVt5kjjI2nIpL_lBuXuGM3bp9QSP_m5k",

  "token_type": "Bearer",

  "expires_in": 7200,

  "scope": "openid profile",

  "created_at": 1667195403,

  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InBkV29RZUdGbkZrdW96X19yU2ZfMW4tblFjdjRCVzd4b2E3RmF5Rk11aUUifQ.eyJpc3MiOiJodHRwczovL3d3dy5zaGFyZS5iZnFhLm9yZy8iLCJzdWIiOiI1MmUwYmZhMTQ2ZjUxYWZlZWQxMDE3MDY3NmEzMWE1MGZmYTAyNTFkZWMzZDIxOTMzNTNiYmNjYzg0NWZiM2RiIiwiYXVkIjoialFQaUZJYWVQcHQ1RVFEYXYwMHpoYV9YdlBta3UyLVNsdHdLY3k3OS10ayIsImV4cCI6MTY2NzE5NTUyMywiaWF0IjoxNjY3MTk1NDAzLCJhdXRoX3RpbWUiOjE2NjcxOTU0MDN9.H2Nv7NrX7IoPvpXgh2o6T6Y7fx-nnjFSxVfsfTfQJS6wmLP-7-vvj_-PTHOvVSComib4aDkBUbyXdOFdiU6LrDGKG4jx16SxUnkoCk2T9baPsXTMn0dFK6SysWHdBexMZigN54gCFkRuY_Una8f_gWoy-vheytqvxCOC_N7ZEIQ5cWAqvYWF92V7vZhqAp4e4ImvYxLtIAHuxATJCXUzvnOPIk9D3sXeTcHw-nHhZiE-_G2L_GNyiw6Aq5o6PI4j_ICBdhedlwg220pR89CbSpsl1BeO6dVQY6T523JYqTNxT9HHU716klBytZE8oHc8kI7wwPUEmZv2bRJip7P4qA"

}

GET /oauth/discovery/keys
200 - OK

After this point my browser is at https://wizehive.poc.cloud.gooddata.com/login/oauth2/code/wizehive.poc.cloud.gooddata.com?code=hi_A-NiwDXM7KNJ8usj2jPIkZWuW4EEdDIvIY18nyUc&state=RorYXYYc2SsLpFW1w-h9-gjYPQvNxoRRb6Fh6hsjGQY%3D with a 401 error

What is happening after the last post to the /token endpoint that is causing the login to fail?
 

icon

Best answer by Peter Plochan 4 November 2022, 16:13

View original

6 replies

Userlevel 3

Hello Scott,

Could you provide response headers from this last 401 response?

There should be WWW-Authenticate header, which could probably explain the reason of the error. If there’s no such header, we need to investigate the problem further.

Just quick question what OIDC provider are you using? This could help as well.
 

www-authenticate: Unable to authenticate: error: [invalid_nonce]

We are using the Ruby gems doorkeeper and doorkeeper-openid_connect. We are not able to use a third party openid service.

Hi @scott.jacobsen,

the invalid_nonce error code from the www-authenticate header means there was a problem with the nonce parameter. Our GD backend expects a proper value of this parameter which must be located within the ID Token returned by the OIDC provider.

Does your “doorkeeper-openid_connect” support sending this parameter? I’ve found some mention about enabling nonces in the related GitHub README, but I’m not sure if it will help. Could you try it?

More info about the nonce within the OIDC standard:

nonce
OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. For implementation notes, see Section 15.5.2.

Hi,

I managed to fix the nonce issue - now it does appear the login works (as far as I can tell)

Here is the jwt token with the nonce:

https://jwt.io/#debugger-io?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InBkV29RZUdGbkZrdW96X19yU2ZfMW4tblFjdjRCVzd4b2E3RmF5Rk11aUUifQ.eyJpc3MiOiJodHRwczovL3d3dy5zaGFyZS5iZnFhLm9yZy8iLCJzdWIiOiI1MmUwYmZhMTQ2ZjUxYWZlZWQxMDE3MDY3NmEzMWE1MGZmYTAyNTFkZWMzZDIxOTMzNTNiYmNjYzg0NWZiM2RiIiwiYXVkIjoiLUlMMTlWR0tnOXZyZjZhM2Z0ZFBtRlpjbHRRaG52QkFCamRlQVAwSDczNCIsImV4cCI6MTY2NzYwNjQ3NiwiaWF0IjoxNjY3NjA2MzU2LCJub25jZSI6IlNVUHBRZ1lYTFU5aExCczVsZ1FzVFV2RndQNF8xdUJOeTc5Zi15QjdFWFUiLCJhdXRoX3RpbWUiOjE2Njc2MDYzNTZ9.OwDRNiSQ8CYQNGqq5E0FMHv-TDDvGOZp07qsstNL84y8kmtFoaCPj5XRxAOHe3aUY3-qZz6cgY0F4JU1lcf3OJuJVFCDjnY_scHJ3MkX2-d-KtuhYj8ge_3TLKwyfeGg-rUR0xAhTdEQHe7mCnlKvJ-6qMLMDiEi3wuSEzc5ho0XifheD9_UAarLa0kTXCgrWO-3YMTRFtyPp1LAIsv7cc6_48-_1FcsM_VSvSNRrFvzKXOh4XSgkb0vZZRDs5mwXU6xjbqKqa5TF-5e-7fSLzTEnlIGbgC2KTOVfNlKbj65jnx8Wjc4DE225l_qp0MiG7mie0mMFNJdCg-ESkpp7A

 

The final call is to the userinfo endpoint, which returns 

 

{

sub:"52e0bfa146f51afeed10170676a31a50ffa0251dec3d2193353bbccc845fb3db"

name:"Gerken Wever"

given_name:"Gerken"

family_name:"Wever"

updated_at:1667604730

zoneinfo:"America/Los_Angeles"

profile:"https://www.brightfunds.org"

}

 

Then it redirects to https://wizehive.poc.cloud.gooddata.com/ which returns a 200, but the screen just says “Unknown Error” “We’re not quite sure what went wrong”

 

According to our logs, it seems there’s a missing name claim in the ID token. The GD backend uses the ID token for getting a user info (name) of the already authenticated session instead of the userinfo endpoint.

Could you, please, try to add at least the name claim to the ID token as well? It seems there’s a how-to in the already mentioned doorkeeper’s README.

Thanks! That was the final piece of the puzzle. Login appears to be working.

Reply