hydra: pkce does not seem to work

Describe the bug

Running hydra v1.0.0 with a postgresql backend, its seems that code_challenge_method, code_challenge and code_verifier are ignored, as it does not make any difference how right or wrong it is used.

Reproducing the bug

curl 'https://auth.hydra.xxx.nl/oauth2/auth?access_type=offline&client_id=radio1-app&code_challenge=ahsbr8liNiieY9JKiSoX0EEVK52xrlGCFvM-zG-Tuhc&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A5555%2Fcallback&response_type=code&scope=openid+profile+email&state=I+wish+to+wash+my+irish+wristwatch'

This should be a valid challenge, the resulting code-to-access-token exchange is always sucessfull no matter how wrong my code_verifier is.

Also setting e.g. code_challenge_method=S257 does not result in some form of error.

Server logs

logs showing how S257 is allowed:

{"level":"info","method":"GET","msg":"started handling request","remote":"145.58.114.228","request":"/oauth2/auth?access_type=offline\u0026client_id=radio1-app\u0026code_challenge=_RpfHqw8pAZIomzVUE7sjRmHSM543WVdC4o-Kc4_3C0\u0026code_challenge_method=S257\u0026redirect_uri=http%3A%2F%2F127.0.0.1%3A5555%2Fcallback\u0026response_type=id_token\u0026scope=openid+profile+email\u0026state=I+wish+to+wash+my+irish+wristwatch","request_id":"244f22dfd4acb49e867323294257871d","time":"2019-08-05T16:04:49Z"}
{"level":"info","measure#hydra/public: https://auth.hydra.xxx.nl/.latency":10941200,"method":"GET","msg":"completed handling request","remote":"145.58.114.228","request":"/oauth2/auth?access_type=offline\u0026client_id=radio1-app\u0026code_challenge=_RpfHqw8pAZIomzVUE7sjRmHSM543WVdC4o-Kc4_3C0\u0026code_challenge_method=S257\u0026redirect_uri=http%3A%2F%2F127.0.0.1%3A5555%2Fcallback\u0026response_type=id_token\u0026scope=openid+profile+email\u0026state=I+wish+to+wash+my+irish+wristwatch","request_id":"244f22dfd4acb49e867323294257871d","status":302,"text_status":"Found","time":"2019-08-05T16:04:49Z","took":10941200}

Server configuration

log:
  level: info
  format: json
serve:
  public:
    port: 4444
    host:
    cors:
      enabled: false
    access_log:
      disable_for_health: false
  admin:
    port: 4445
    host:
    cors:
      enabled: false
    access_log:
      disable_for_health: false
  tls:
dsn: postgres://hydra:password@sqlproxy:5432/hydradb?sslmode=disable
webfinger:
  jwks:
    broadcast_keys:
      - hydra.openid.id-token # This key is always exposed by default
  oidc_discovery:
    client_registration_url: https://my-service.com/clients
    supported_claims:
      - email
      - username
    supported_scope:
      - email
      - whatever
      - read.photos
    userinfo_url: https://example.org/my-custom-userinfo-endpoint
oidc:
  subject_identifiers:
    enabled:
      - pairwise
      - public
    pairwise:
      salt: some-random-salt
  dynamic_client_registration:
    default_scope:
      - openid
      - offline
      - offline_access
urls:
  self:
    issuer: https://auth.hydra.xxx.nl
    public: https://auth.hydra.xxx.nl
  login: https://login.hydra.xxx.nl/login
  consent: https://login.hydra.xxx.nl/consent
  post_logout_redirect: https://usabilitygeek.com/ux-logout-lapse/
strategies:
  scope: DEPRECATED_HIERARCHICAL_SCOPE_STRATEGY
ttl:
  login_consent_request: 1h
  access_token: 1h
  refresh_token: 720h
  id_token: 1h
  auth_code: 10m
oauth2:
  expose_internal_errors: true
  hashers:
    bcrypt:
      cost: 10
secrets:
  system:
    - this-is-the-primary-secret
    - this-is-an-old-secret
    - this-is-another-old-secret
  cookie:
    - this-is-the-primary-secret
    - this-is-an-old-secret
    - this-is-another-old-secret
tracing:
  provider:

Expected behavior

I expected an error on getting the accesstoken using a false code_verifier Also I expect errors when using unsupported code_challenge_method or too short code_challenge’s

Environment

Docker/kubernetes

  • v1.0.0

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (9 by maintainers)

Commits related to this issue

Most upvoted comments

If you have a MITM PKCE won’t do you any good. I’m sorry but that’s just not what PKCE does and that’s not how network security works and no hashed string will ever protect you from eavesdropping network connections.

Feel free to read the spec yourself if you do not trust us to make the right calls: https://tools.ietf.org/html/rfc7636

The people that wrote the spec (check the title for the public part) are pretty good at what they’re doing.

Hydra is not on par with Okta or Cognito. It excels both with better defensive mechanisms and real controls to keep you from making mistakes (like this one). I mean Okta uses security questions for recovering Admin Accounts (iCloud hacks anyone?). Hydra is more flexible, faster, more lightweight and open source.

On 6. Aug 2019, at 09:32, leo-baltus notifications@github.com wrote:

Consider the case of client behind a loadbalancer which does tls termination leaving the last part of the connection (LB to client) over plain http. I think a client could benefit from the extra measure. Hydra would also be on par with Okta, Cognito etc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.