Skip to content

@hono/oidc-auth no longer supports Google Auth with version 1.8.3 #1992

Description

@hamish-milne

Which middleware has the bug?

@hono/oidc-auth

What version of the middleware?

1.8.3

What version of Hono are you using?

4.12.26

What runtime/platform is your app running on? (with version if possible)

Cloudflare Workers

What steps can reproduce the bug?

Use oidcAuthMiddleware with the Google Auth Platform

What is the expected behavior?

Normal login behaviour.

What do you see instead?

OAuth2Error: [invalid_client] The OAuth client was not found.

Additional information

This issue is caused by a confluence of problems:

  1. Google's OAuth implementation uses certain characters (., -, and _) within the Client ID and Client Secret which the OAuth standard requires to be %-encoded. However, HTTP does not require this, and indeed Google Auth will not accept %-encoded values, considering them to be different strings and therefore causing the invalid_client error.
  2. The oauth4webapi library made a breaking change in version 3 which causes these strings to be %-encoded in order to conform with the spec, with no simple way to override this. Others have pointed out that the library no longer works with Google Auth, but the library maintainer is adamant about strictly following the spec: client_secret_basic does not works with google with this lib panva/oauth4webapi#165
  3. This issue is seemingly limited to the client_secret_basic mechanism, which the middleware uses exclusively, again with no simple way to change this to, for example, client_secret_post which is not affected.
  4. The middleware moved to oauth4webapi major version 3 in its own patch version 1.8.3 expecting that any breaking changes would not be user-facing.

My suggestion would therefore be:

  1. For now, revert to oauth4webapi version 2 in the 1.8.x branch. Then:
  2. In a future version 1.9, implement a custom ClientAuth that uses the previous URL-encoding scheme, un-breaking the change in the dependency, Or:
  3. In a future version 2.0, use the default ClientAuth, but allow the user to specify their own which is passed through to the library, providing an escape hatch for any future similar issues.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions