What causes "invalid x coordinate: %w" in OpenNHP/opennhp?

Encode JWK coordinates with base64.RawURLEncoding (unpadded URL-safe) on the client.

invalid x coordinate

Error message

invalid x coordinate: %w

What it means

The 'x' coordinate string must decode as unpadded base64url (RawURLEncoding); if decoding fails, VerifyJWT returns 'invalid x coordinate: %w' wrapping the base64 error. This catches wrong padding, illegal characters, or wrong encoding variant in the JWK coordinate.

Solutions

Encode JWK coordinates with base64.RawURLEncoding (unpadded URL-safe) on the client.
Strip whitespace/newlines from coordinate strings before embedding.
Check the wrapping base64 error in the log — illegal character vs padding tells you which variant was used.
If the producer emits padded base64, decode offline and re-encode unpadded, or fix at the source.
Regenerate the token with the reference client/library to guarantee correct encoding.

Example fix

// before
xB64 := base64.StdEncoding.EncodeToString(xBytes)
// after
xB64 := base64.RawURLEncoding.EncodeToString(xBytes)

Defensive patterns

Strategy: validation

Validate before calling

func isRawURLB64(s string) bool {
	_, err := base64.RawURLEncoding.DecodeString(s)
	return err == nil
}
// isRawURLB64(jwk["x"].(string)) before calling VerifyJWT

Try / catch

token, err := VerifyJWT(rawToken)
if err != nil && strings.Contains(err.Error(), "invalid x coordinate") {
	// bad encoding from client: return 401 and log the base64 cause
}

Prevention

Always use base64.RawURLEncoding for JWK members.
Strip whitespace/newlines from coordinates.
Never mix StdEncoding and RawURLEncoding in one header.
Validate tokens locally before sending.
Prefer library-generated headers over manual assembly.

When it happens

Trigger: jwk.x uses standard base64 with '=' padding, contains '+' or '/' instead of '-' and '_', includes whitespace/newlines, or is otherwise not valid base64url. Reached during GetResource token verification.

Common situations: Client encodes coordinates with StdEncoding instead of RawURLEncoding; JWT header JSON was re-encoded with padded base64 by an intermediary; copy-paste introduced whitespace or line breaks.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of OpenNHP/opennhp@6e04ca5ff0 (2026-09-07). Data as JSON: /api/errors/c4a76dc5527dcb66. Report an issue: GitHub.

Appendix: source

Thrown at endpoints/server/kbs/resource/resource.go:237

	// Extract JWK from header
	jwkHeader, ok := unverifiedToken.Header["jwk"].(map[string]any)
	if !ok {
		return nil, fmt.Errorf("missing or invalid jwk in header")
	}

	// Convert JWK back to ECDSA public key
	xStr, ok := jwkHeader["x"].(string)
	if !ok {
		return nil, fmt.Errorf("missing x coordinate in jwk")
	}
	yStr, ok := jwkHeader["y"].(string)
	if !ok {
		return nil, fmt.Errorf("missing y coordinate in jwk")
	}

	xBytes, err := base64.RawURLEncoding.DecodeString(xStr)
	if err != nil {
		return nil, fmt.Errorf("invalid x coordinate: %w", err)
	}
	yBytes, err := base64.RawURLEncoding.DecodeString(yStr)
	if err != nil {
		return nil, fmt.Errorf("invalid y coordinate: %w", err)
	}

	publicKey := &ecdsa.PublicKey{
		Curve: elliptic.P256(),
		X:     new(big.Int).SetBytes(xBytes),
		Y:     new(big.Int).SetBytes(yBytes),
	}

	// Now verify the token with the extracted public key
	token, err := jwt.Parse(tokenString, func(token *jwt.Token) (any, error) {
		// Check signing method
		if _, ok := token.Method.(*jwt.SigningMethodECDSA); !ok {
			return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
		}

View on GitHub (pinned to 6e04ca5ff0)