OIDC : id token signed with unsupported algorithm, expected ["RS256"] got "HS512"

SebBlin commented 4 years ago

/kind bug

What steps did you take and what happened: I were able to setup authentication with OIDC-authservice and dex as proposed by Arrikto. I'm working with an external OIDC identity provider, declared as OIDC connector in dex. When the user is redirected to the callback URL, I get the following message in the browser:

Failed to authenticate: oidc: failed to verify ID Token: oidc: id token signed with unsupported algorithm, expected ["RS256"] got "HS512" I can also retrieve the same error message in logs from the dex container.

Anything else you would like to add: The identity provider I'm using is lemonLDAP which is configured as OIDC identity provider.

Environment: I'm working in a private network in which I have a private Kubernetes that execute kubeflow. Kubeflow is exposed through a revers proxy with a public URL and have access to Internet through a forward proxy (to make everything work, I had to add an overlay on both dex and oidc-authservice, to add http_proxy env vars)

As I'm using an external OIDC Identity provider, to avoid dead lock, I had to use the dedicated patch for oidc-authservice provided in branch "https://github.com/yanniszark/oidc-authservice/tree/feature-server-start-immediately" and corresponding to the image "gcr.io/arrikto/kubeflow/oidc-authservice:b8ebd88" (in fact I made a fork of this image because I needed to add private CA certificates that is used to to generate TLS certificates for our OIDC IDP)

Kubeflow version: build version 0.7.0:
kfctl version: v0.7.0:
Kubernetes platform: home made Kubernetes
Kubernetes version: 1.13.10:

issue-label-bot[bot] commented 4 years ago

Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.

yanniszark commented 4 years ago

Hi @SebBlin!

First of all, regarding the custom CA. We want to support that and we don't want you to have to make a new image for this. I have opened https://github.com/arrikto/oidc-authservice/issues/9 to track this issue.

Secondly, could you give me the information of your OIDC Provider's well-known endpoint? It will assist me in debugging this issue.

SebBlin commented 4 years ago

Hi @yanniszark

here is the configuration (I've changed the domain name :-) )

{
  "response_types_supported": [
    "code",
    "id_token",
    "id_token token",
    "code id_token",
    "code token",
    "code id_token token"
  ],
  "id_token_signing_alg_values_supported": [
    "none",
    "HS256",
    "HS384",
    "HS512",
    "RS256",
    "RS384",
    "RS512"
  ],
  "userinfo_endpoint": "https://kubeflow.mydomain.org/oauth2/userinfo",
  "backchannel_logout_supported": true,
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "address",
    "phone"
  ],
  "userinfo_signing_alg_values_supported": [
    "none",
    "HS256",
    "HS384",
    "HS512",
    "RS256",
    "RS384",
    "RS512"
  ],
  "token_endpoint": "https://kubeflow.mydomain.org/oauth2/token",
  "end_session_endpoint": "https://kubeflow.mydomain.org/oauth2/logout",
  "authorization_endpoint": "https://kubeflow.mydomain.org/oauth2/authorize",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "require_request_uri_registration": false,
  "request_parameter_supported": true,
  "frontchannel_logout_session_supported": true,
  "claims_supported": [
    "sub",
    "iss",
    "auth_time",
    "acr"
  ],
  "request_uri_parameter_supported": true,
  "jwks_uri": "https://kubeflow.mydomain.org/oauth2/jwks",
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ],
  "frontchannel_logout_supported": true,
  "issuer": "https://kubeflow.mydomain.org",
  "backchannel_logout_session_supported": true,
  "subject_types_supported": [
    "public"
  ],
  "check_session_iframe": "https://kubeflow.mydomain.org/oauth2/checksession.html",
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "hybrid"
  ],
  "acr_values_supported": []
}

yanniszark commented 4 years ago

I see, this is definetely an issue. What's happening is that the go-oidc library that we use doesn't save the supported signing values internally as I thought it would and assumes a default of RS256.

I can think of 2 solutions:

Patch the library to support this use-case. I have made an issue in their repo: https://github.com/coreos/go-oidc/issues/225
Add a supported algorithms option to the authservice and pass them to the verifier config. This can help remedy the problem immediately, but ideally I'd love for this to be solved in the library.

yanniszark commented 4 years ago

/priority p1 /kind bug

SebBlin commented 4 years ago

I really thank you for investigating ! Do you think about a possible workaround (even a dirty one) that I could use, to make it work and that would allow me to go forward ?

yanniszark commented 4 years ago

It seems the issue could not be resolved as I thought. The go-oidc library may not support HS512 altogether. @SebBlin a quick fix would be to make your OIDC provider use RSA256 instead. From the list in the well-known endpoint, I see it supports it. Could you see if you can configure it?

SebBlin commented 4 years ago

Yes, I'm asking for it.

SebBlin commented 4 years ago

The request to use RS256 has been accepted by the team and is ongoing. I should be able to test it soon.

SebBlin commented 4 years ago

The configuration with RS256 was made but now I'm facing a new error message: Failed to authenticate: oidc: failed to verify ID Token: oidc: malformed jwt: illegal base64 data at input byte 59 I will continue investigations.

yanniszark commented 4 years ago

@SebBlin did you manage to triage the aforementioned issue?

SebBlin commented 4 years ago

Hello @yanniszark, sorry for the delay. Just yesterday, I was able to find the root cause of this issue : the OIDC Identity provider I'm using has a bug and the JWS token (id_token) it sends is indeed malformed. The Base64 encoding still include trailing "="; that is not allowed in JWT/JWS. There is a patch for it; I just requested to the team charge of this IDP to install this patch.

In the meantime, I also developed a patched release of DEX (just for my own, to be able to continue investigations) and now, I'm facing another new issue : "Failed to authenticate: oidc: failed to verify ID Token: failed to verify signature: failed to verify id token signature".

It seems I miss some configuration in my config file to enable DEX to validate the signature part of the 'id_token'. I continue investigations.

As the original issue is now corrected, should we close this thread ? or should we keep it open until I'm able to authenticate from 'end-to-end' ?

yanniszark commented 4 years ago

@SebBlin that's nice to hear! So the conclusions from this issue are:

Currently, OIDC-AuthService currently only supports RS256 for token verification.
A go-oidc library author is open to adding support for more asymmetric algorithms, but is unsure about symmetric algorithms like HS512. (https://github.com/coreos/go-oidc/issues/225#issuecomment-562685492).

I also opened https://github.com/arrikto/oidc-authservice/issues/12 in order to add this restriction to the oidc-authservice docs. I believe we should close this issue as the original problem was investigated and resolved. Let's address other problems in follow-up issues.

yanniszark commented 4 years ago

/close

k8s-ci-robot commented 4 years ago

@yanniszark: Closing this issue.

In response to [this](https://github.com/kubeflow/kubeflow/issues/4550#issuecomment-572030872): >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kubeflow / kubeflow

OIDC : id token signed with unsupported algorithm, expected ["RS256"] got "HS512" #4550