We are using Open Secret to generate third party token with generateThirdPartyToken method from Open Secret SDK. This JWT is signed with secret that we provide in the Open Secret dashboard project settings. The same secret is shared with Supabase platform when creating Supabase JWT key. Then, when reading data from our Supabase database, we pass the token obtained from generateThirdPartyToken and then Supabase can verify it (because of the shared secret) and decode to get user id and role which are then used to check if the user has access to requested data. This worked well but recently they released new type of JWT signing keys (see here) and deprecated the old approach which will eventually be completely dropped (late 2026 probably).
The new approach in Supabase enables users to have more than one JWT key. The new JWT keys are identified with id and can also be created with a shared secret. However, since there can be more than one, when Supabase receives a request with a JWT token, it needs to know which JWT key from the Supabase keys to select to verify the token and it does so by using the key id. It expects the JWT header payload to have kid claim with the key id value. If it doesn't find it, it returns invalid JWT error and thus the authorization fails. Docs for kid can be seen here.
The problem is that the JWT token created by generateThirdPartyToken doesn't have kid in the token header. Thus we need a way to provide one to Open Secret which then needs to add it to the token header.
Possible solutions:
generateThirdPartyToken adds a new optional kid param which if set, ends up in the token header.- Open Secret dashboard is updated to allow entering the
kid value when configuring the project. This value is then added to the header of every JWT generated by generateThirdPartyToken
Option 1 seems better to me.
We are using Open Secret to generate third party token with
generateThirdPartyTokenmethod from Open Secret SDK. This JWT is signed with secret that we provide in the Open Secret dashboard project settings. The same secret is shared with Supabase platform when creating Supabase JWT key. Then, when reading data from our Supabase database, we pass the token obtained fromgenerateThirdPartyTokenand then Supabase can verify it (because of the shared secret) and decode to get user id and role which are then used to check if the user has access to requested data. This worked well but recently they released new type of JWT signing keys (see here) and deprecated the old approach which will eventually be completely dropped (late 2026 probably).The new approach in Supabase enables users to have more than one JWT key. The new JWT keys are identified with id and can also be created with a shared secret. However, since there can be more than one, when Supabase receives a request with a JWT token, it needs to know which JWT key from the Supabase keys to select to verify the token and it does so by using the key id. It expects the JWT header payload to have
kidclaim with the key id value. If it doesn't find it, it returns invalid JWT error and thus the authorization fails. Docs forkidcan be seen here.The problem is that the JWT token created by
generateThirdPartyTokendoesn't havekidin the token header. Thus we need a way to provide one to Open Secret which then needs to add it to the token header.Possible solutions:
generateThirdPartyTokenadds a new optionalkidparam which if set, ends up in the token header.kidvalue when configuring the project. This value is then added to the header of every JWT generated bygenerateThirdPartyTokenOption 1 seems better to me.