Use go-jose for JWS parsing

[asweet-confluent]

go-oidc contains parseJWT, which has the same vulnerability as go-jose: CVE-2025-27144. Instead of copying the updated code from go-jose, I opted to get rid of parseJWT entirely and rely on go-jose for parsing. That led to a series of changes:

• The test unsigned token InsecureSkipSignatureCheck started failing because it was generating invalid JWSs that lacked the final . required for unsecured JWTs.
• Fixing that revealed that the hardcoded test header did not contain valid JSON.
• Fixing that led to go-jose failing with unexpected signature algorithm "none"; expected ["RS256"]. I addressed that by explicitly enabling the none algorithm when InsecureSkipSignatureCheck is set.

This is technically a breaking change since parseJWT required two or more .s in a JWS and would ignore the signature part, whereas go-jose is stricter about JWS correctness.

[ericchiang]

Thanks so much for brining this up!

Thinking about this, if we're going to try to be resistant to pre-signature validation memory consumption, we probably want to reverse the order of operations and verify the JWT signature before checking claims. Currently we parse the JWT first to throw out bad values.

As it stands, you can craft a payload that causes excessive memory allocation. Imagine some claims that look like the following. That'd have basically the same affect as the CVE you've linked to.

{
    "aud": [".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ...]
}

Would you like to update this PR to do that? I'm happy to do that if not.

[asweet-confluent]

That's a good idea; please take it up if you have the time.

[ericchiang]

I went ahead and tagged https://github.com/coreos/go-oidc/releases/tag/v3.15.0

Thanks so much for reporting!