Custom OIDC Provider: LINE Login fails with "unexpected algorithm, expected ES256 got HS256"

[fromisantoisan]

I've set up LINE Login (https://developers.line.biz) as a Custom OAuth/OIDC
Provider in Supabase Auth (Auto-discovery method, issuer:
https://access.line.me).

The authorization flow completes successfully (user approves on LINE's
side, redirect back works), but the sign-in fails at the final step with:

error=server_error&error_code=unexpected_failure&
error_description=Error+getting+user+profile+from+external+provider

Checking the Auth Logs in the dashboard shows the underlying cause:

Failed to verify ID token: oidc: id token signed with unsupported
algorithm, expected ["ES256"] got "HS256"

According to LINE's own documentation
(https://developers.line.biz/en/docs/line-login/verify-id-token/), this is
expected behavior: LINE signs ID tokens with ES256 for native
apps/SDK/LIFF, but with HS256 (using the Channel Secret as the HMAC key)
for web-based login flows. This is not configurable on LINE's side.

Is there a way to configure the Custom OIDC Provider in Supabase to accept
HS256-signed ID tokens (using the Client Secret as the HMAC verification
key), either via the dashboard or via a config option? Or is this a
fundamental limitation of the current custom provider implementation?

Happy to provide more details (redacted logs, config) if useful.

[GaryAustin1]

I don't have suggestions on a workaround but Supabase custom oath is ES256 only.
Check with an AI and search on LINE/Supabase would be my suggestions if no one else comes along with a work around.

[pacocartones]

The expected ["ES256"] in that log is not a Supabase policy — it is LINE's own value, read back from LINE's discovery document. That changes what can be done about it.

$ curl -s https://access.line.me/.well-known/openid-configuration
{ … "jwks_uri": "https://api.line.me/oauth2/v2.1/certs",
      "id_token_signing_alg_values_supported": ["ES256"], … }

Auth verifies the ID token with provider.Verifier(config) (supabase/auth, internal/api/provider/oidc.go:41) on github.com/coreos/go-oidc/v3 v3.20.0 (go.mod). Two things in that library close the door:

1. Provider.newVerifier fills SupportedSigningAlgs from the discovery document whenever the caller left it empty (oidc/verify.go:136-145). With auto-discovery against https://access.line.me, that is ["ES256"] — verbatim from the JSON above.
2. Even if LINE advertised HS256, it would be dropped on the way in. supportedAlgorithms (oidc/oidc.go:180-191) lists RS/ES/PS/EdDSA only, and discovery values are filtered through it (oidc/oidc.go:337-342). The comment on that map says it outright: "If a provider supports other algorithms, such as HS256 or none, those values won't be passed to the IDTokenVerifier."

So there is no dashboard toggle and no config value that makes this work: the verifier in use cannot do HMAC at all, and nothing you could put in SupportedSigningAlgs would survive step 2.

The deeper reason it is not fixable by relaxing an algorithm list: LINE's HS256 web-login token is signed with your Channel Secret, and that key is published nowhere. https://api.line.me/oauth2/v2.1/certs returns only {"kty":"EC","alg":"ES256",…} keys, and LINE's own header table states that kid is "Included in a header only when the value of alg is ES256". An HS256 token from LINE web login therefore carries no kid and its key is not discoverable — no discovery-based OIDC client can verify it, by construction rather than by anyone's choice.

Which leaves the practical route: keep LINE out of the Custom OIDC provider and do the exchange yourself in an Edge Function — trade the code at https://api.line.me/oauth2/v2.1/token, verify the ID token either locally with the Channel Secret or through LINE's own POST https://api.line.me/oauth2/v2.1/verify, then create or sign in the user via the Admin API. Per the same LINE doc, the ES256 path is only produced for "native apps, LINE SDK, or LIFF apps" — so it is not something a web login flow can opt into, and Custom OIDC stays out of reach for that flow specifically.