Repository navigation
Description
Preflight Checklist
- I could not find a solution in the existing issues, docs, nor discussions
- I have joined the ZITADEL chat
Describe your problem
Hello, I want to use zitadel/oidc for creating relying party. I use telegram as OP. I checked app example, changed all required variables to the credentials which telegram gave me (clientID, clientSecret, issuer). When I login through 127.0.0.1:8080/login, this is what callback returns:
Details
failed to exchange token: invalid signature (unable to fetch key for signature validation: oidc: failed to get keys: failed to unmarshal response: oidc: failed to unmarshal key 3 from set: go-jose/go-jose: unsupported elliptic curve 'secp256k1' {
"keys": [
{
"alg": "RS256",
"e": "AQAB",
"ext": true,
"key_ops": [
"verify"
],
"kty": "RSA",
"n": "5RneLtsKvVcxdv6gu6gxEQu30Cru5NiMQnY6SNr9ZyZFZ4ya-pfHNuaZXJ6QPG0JSFwoxeOkEO2-eZN_REVPm448PvjjsR1eQdZ5QpEkNxnItFcmxkHH91v5cgf52_EI9BGO-MT6f1vaBSg3uWHFlDxI7J2AYxNvd1_Nf3TkgrrR7gyJFTmEIai5RefGnA0KGNYDlRIGUzrz2F05n6gTaHFT_iHL5UHatTZA4GCiUSjIOuwqu5pE5uZge20TFv3cxXMQaFw_xv1pgQt_Rq8eoCN7TS0RQ0zjWKiad-W286BcFectXsUm03p5Nq_kY4mf_7rqwX_B8yy_bBreyKn7RQ",
"kid": "oidc-1"
},
{
"alg": "ES256",
"kty": "EC",
"x": "ahVYrohhX6YA7w0P2gUNSwMFbaabCgBZFkeq9bWdmwU",
"y": "Ea8nKJ34VQMA7zv8aYDfzcBhXEjnWQ9C06jVke_eUV0",
"crv": "P-256",
"kid": "oidc-es256-1",
"use": "sig"
},
{
"alg": "EdDSA",
"crv": "Ed25519",
"x": "i6BEafXMEe4osXgUTffpKAm6Cn6F2bhqPZoclunTAV4",
"kty": "OKP",
"kid": "oidc-eddsa-1",
"use": "sig"
},
{
"alg": "ES256K",
"kty": "EC",
"x": "vsk5i5YJu8H_VPL7DWTgVGXBPrqgkyNmYvfgOrVut38",
"y": "Mrg56tBhVeorHPXK1LbTX2jP7rEqOHIatM96HFzVMIU",
"crv": "secp256k1",
"kid": "oidc-es256k-1",
"use": "sig"
}
]
})
I suppose this happens because go-jose doesn't support secp256k1. I'm not an expert in oidc and related things like jwt, but comments in these pull requests (first, second) state that there will be no support for this kind of signature until standard library supports curve.
Describe your ideal solution
I don't know exactly what is the ideal solution: I guess you won't implement itself this signature or change to another jwt package which supports it, however maybe zitadel can influence on https://github.com/go-jose/go-jose maintainers so this signature would be implemented ? I guess this go-jose's package already implements some signatures, so it would be a good place to secp256k1 implementation. Thanks
Version
% go list -m all | rg zitadel/oidc
github.com/zitadel/oidc/v3 v3.47.5
Environment
Self-hosted
Additional Context
No response
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Projects
- StatusShow more project fieldsNo status
Activity
ulibaysya commentedon Jul 4, 2026
I've discovered that telegram signs tokens with
RS256(ref) and gives an opportunity to sign tokens withES256K(orsecp256k1, this is a signature that I mentioned in previous message). However, it anyway fails.I suppose code fails on this line. Description for UnmarshalJSON states:
And I suppose that
ES256Kis a supported "key type". However, "curve"secp256k1is not supported by go-jose, this is why go-jose returns this error (ErrUnsupportedEllipticCurve). zitadel/oidc checks only ErrUnsupportedKeyType. This is why fail occured when I tried to implement relying party with example codeSo, I can also suggest to check for elliptic curve error when unmarshalling jwks as a solution to my initial issue.
Also I can suggest to add an API to skip unmarshalling some kinds of signatures/curves/algorithms when fetching jwks at all, but maybe this is too large and needless
0xch commentedon Oct 9, 2026
I have the same issue.
Apparently the problem is not with accepting a new algo, but with unrecognized algo on the list provided by Telegram OP.
Supabase had the same problem: supabase/auth#2534
Telegram’s OIDC provider (issuer https://oauth.telegram.org) publishes four keys in its JWKS: RS256, ES256 (P-256), EdDSA (Ed25519) and ES256K (secp256k1). Login via a generic OIDC IdP fails after the Telegram callback with error:
The ID token itself is signed with a supported key, but the whole key set is rejected because of one unsupported key.
Expected: skip keys that can’t be parsed and verify with the remaining ones.