oidc-agent fails with "Could not find a public client for this issuer." when adding multiple shortname for a single issuer

[olifre]

Trying to execute:

oidc-gen punch-aai --pub --iss https://login.helmholtz.de/oauth2 --scope="openid profile offline_access"

did yield the error:

Could not find a public client for this issuer.

for me, while this issuer clearly has a public client defined in shipped config. This was seen on a system using oidc-agent since version 3.3.1.

Running:

mv ~/.config/oidc-agent{,-old}

fixed it, i.e. oidc-gen worked fine again with the same commandline.

Presumably, the ~/.config/oidc-agent/issuer.config was broken. Checking the old one, I find:

$ cat ~/.config/oidc-agent-old/issuer.config| jq '.[] | select(.issuer | startswith("https://login.helmholtz.de/oauth2"))'
{
  "issuer": "https://login.helmholtz.de/oauth2/",
  "accounts": [
    "helmholtz",
    "punch-aai"
  ]
}
{
  "issuer": "https://login.helmholtz.de/oauth2",
  "pubclient": {
    "client_id": "public-oidc-agent",
    "client_secret": <redacted>
  },
  "register": "https://login.helmholtz.de/"
}

Note the different canonicalization, i.e. one of the two contained an additional / for the issuer. Probably that confused oidc-agent?

I'm not sure this is a bug (or at least not a bug still present in the current code), but since it may hit other users, I am wondering whether there would be a way to handle this case.

[olifre]

Update: I realized only now that even after flushing my ~/.config/oidc-agent completely, after using oidc-gen with different shortname for the same issuer more than three times, I run into the same problem.

So it seems the bug is not due to version history, but still present in current versions.

[marcvs]

Which version of oidc-agent are you using? We changed the config from version 4 to 5

[marcvs]

In any case, please also check /etc/oidc-agent/*

[marcvs]

For version 5, my /etc/oidc-agent/issuer.config.d/helmholtz looks like:

{
  "issuer": "https://login.helmholtz.de/oauth2",
  "register": "https://login.helmholtz.de/",
  "pubclient": {
    "client_id": "public-oidc-agent",
    "client_secret": "rE9CsA4T4UkgSVccErSD"
  }
}

[olifre]

@marcvs That's also how it looks for me. Things break once I try to add the fourth shortname for the same issuer, even after completely purging ~/.config/oidc-agent.

[zachmann]

I'll look into it. But you're right it is very likely linked to the (not) trailing slash. oidc-agent is generous with that and handles them as the same issuer. So when it looks for helmholtz it will only use one of these.

I'll look into it how it might be improved.

[olifre]

Indeed.

In fact, I think the main issue is that oidc-agent itself will add the section with trailing slash to ~/.config/oidc-agent/isser.config when adding multiple shortnames, hence causing the problem. So maybe it's just an extra canonicalization going on which breaks things here.

[zachmann]

From what I had in my head and also when I looked into the code and what I tested, I would say that oidc-agent should handle the case where there is one form in the issuer.config and the issuer from an account config in another form and it should still be added correctly to the already existing entry in the issuer.config.

Could you please try (again) the following:

• Edit the issuer.config in use to only have the entry without the trailing slash that has the pubclient entry, but no accounts, i.e. removing the other entry
• Restart the agent
• oidc-add the accounts
• Check the issuer.config file

[olifre]

• Edit the issuer.config in use to only have the entry without the trailing slash that has the pubclient entry, but no accounts, i.e. removing the other entry

• Restart the agent

• oidc-add the accounts

• Check the issuer.config file

This did in fact work correctly. No matter how many accounts I add, the config does not break. :+1:

Would it be possible that an older oidc-agent version has added the variant with trailing slash at some point for the account config? Restoring the ~/.config/oidc-agent/issuer.config I used previously (never edited manually) and restarting oidc-agent afterwards, I can reproduce the problem again.