Bearer Token Validation - JWT HS256 about krakend-jose

[kpacha]

@foxcool ,

you can expose private, public and symmetric keys via JWK (https://github.com/devopsfaith/krakend-jose/blob/master/fixtures/symmetric.json).

how do you control the access to your key service is out of the scope of this project (but maybe you could use IAM roles)

cheers

[kpacha]

hi, @ricmoreira !

That log message appears when your token has no kid header with the key ID.

Inspecting the sample token you provided with the jwt.io debugger you can see the headers:

{
  "alg": "HS256"
}

In order to be able to verify their signature, you should issue your JWTs with the key ID (as defined at your JWK, "kid":"key1")

Cheers!

[ricmoreira]

You're the man @kpacha ! Thanks!

[foxcool]

If I use HMAC-SHA 256 algo, why I need to have jwk-url?

I want to set symmetric key on my auth service and my krakenD based gateway by config, and check:

• mandatory only check signature by sectret key
• check roles (if used in extra-config)
• check userID (also)
• another checks by jwt claims.

[kpacha]

Hi, @foxcool

the JWK are consumed from remote services because we choose to reject the 'problems' related to key management (like security and key rotation) and also, we focused on keeping the JOSE module as small and simple as possible.

security

keeping your secrets in your codebase is not best practice (or in the CI pipe or the filesystem). From the RFC 7517:

One should place no more trust in the data cryptographically secured by a key than in the method by which it was obtained and in the trustworthiness of the entity asserting an association with the key. Any data associated with a key that is obtained in an untrusted manner should be treated with skepticism.

That is why we recommend adding the fingerprints of the certificate used by the JWK server so the KrakenD can verify the source of the keys it is using.

operational complexity

orchestrating a cluster of KrakenD nodes should not require anything but deploying a small binary with a single config file

other key managers and backends

adding support for other backends and more complex key managers like vault is in the long-term roadmap

cheers!

[foxcool]

Ok.
Thank you for reply!
But, if we use symmetric algo (like HMAC-SHA), we need to store key secretly (only private key. No public keys or certificates). This case is not implemented?

[alombarte]

Hi @foxcool, I think this will clear your doubts:

https://www.krakend.io/docs/authorization/jwt-signing/ <-- Sign tokens with the private key
https://www.krakend.io/docs/authorization/jwt-validation/ <-- Validate tokens with the public key

[foxcool]

Hi, @alombarte!
I read this docs. But I don't know, how can I do validation with symmetric algo like HMAC-SHA256. This algo haven't Public key, if I don't mistake.

[foxcool]

@kpacha ,
in your example service config not found.
Is this example service can validate route access by roles?
How to write krakend config with JWT validation and SHA-256?

[kpacha]

@foxcool I think we should move the conversation over to slack... because your questions are not related to the issue

cheers

[foxcool]

ok, thank you!

[bariis]

package jwt

import (
	"github.com/golang-jwt/jwt"
	"time"

	"github.com/google/uuid"
)

type token struct {
	UserID uuid.UUID `json:"user_id"`
	jwt.StandardClaims
}

type TokenResponse struct {
	AccessToken token `json:"access_token"`
}

func GenerateToken(userID uuid.UUID) token {
	return token{
		UserID: userID,
		StandardClaims: jwt.StandardClaims{
			ExpiresAt: time.Now().Add(time.Hour * 72).Unix(),
			Audience:  "http://krakend:5000",
			Issuer:    "http://identityservice:5002",
		},
	}
}

This is how I issue my token and then Krakend signes itself. Where should I exactly put the kid insider token header?

[github-actions]

This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.