[Bug]: No error checking if keys are empty

[ghstahl]

[Bug]: No error checking if keys are empty

[ghstahl]

oddly enough I got into this at some point and it has a signing key.

// SigningKey implements the op.Storage interface
func (o *OPStorage) SigningKey(ctx context.Context) (key op.SigningKey, err error) {
	err = retry(func() error {
		key, err = o.getSigningKey(ctx)
		if err != nil {
			return err
		}
		if key == nil {
			return zerrors.ThrowInternal(nil, "test", "test")
		}
		return nil
	})
	return key, err
}

[hifabienne]

@livio-a @muhlemmer can you help here?

[muhlemmer]

Can you check this discussion and answer and see if the same applies to your situation: #7198

[ghstahl]

Ok I get where the bug is.
@muhlemmer "After a private key expires the new keypair is only created (ad-hoc) when a new token that needs to be signed is requested. (For example an ID token or access token as JWT)."

When a client makes a call to the JWKS enpoint Zitadel MUST return public keys. It doesn't matter if anything has not yet used the private key to sign. When someone ask you for something then give it to them.

It is unacceptable to have an empty public key response.

I would copy that so called (ad-hoc) code to cover both cases.

Also, this discussion, Seamless JWKs rotation cannot be ignored. There is a reason your competitors have it.

I guess I can get my devops guys to automate a login every 5 minutes to ensure that Zitadel creates keys. :(

[muhlemmer]

It is unacceptable to have an empty public key response.

That's a matter of opinion, but not a valid bug report.

Also, this discussion, #5690 cannot be ignored. There is a reason your competitors have it.

Why even raise a bug if you are already part of the discussion regarding JWKs rotation. Put effort in the discussion, or come with a decent proposal or PR that solves a problem for you.

Voting to close @hifabienne, @livio-a because:

• Currently behaves as designed.
• Current behavior is documented.
• Current behavior is explained in discussion: #7198
• OP is already part of a discussion in changing the design #5690

Alternatively this can be reshaped in a feature request and/or merged with the seamless design.

[ghstahl]

I raised it as a bug because there are going to be enterprise clients (our customers) that will poll for a JWKS and zitadel will return nothing. They have old stuff and don't do on-demand pulling of keys.

This means that all tokens used will fail validation.

I would argue that this is a critical show stopper vs a bug.

This is the current land scape of clients using auth and I really don't want to have a conversation with a customer saying.
Well Zitadel has it documented, good luck!

[ghstahl]

BTW: Zitadel may fail OIDC specifications over this.

oidc spec

I don't think there is carve out to say "we didn't use a private key to sign anything yet so no public keys".

I don't think it's a matter of opinion that keys MUST be returned even if nothing has been signed by their private key half.

15.2.  Mandatory to Implement Features for Dynamic OpenID Providers
In addition to the features listed above, OpenID Providers supporting dynamic establishment of relationships with RPs that they do not have a pre-configured relationship with MUST also implement the following features defined in this and related specifications.

Response Types
These OpenID Providers MUST support the id_token Response Type and all that are not Self-Issued OPs MUST also support the code and id_token token Response Types.
Discovery
These OPs MUST support Discovery, as defined in [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-core-1_0.html#OpenID.Discovery) [OpenID.Discovery].
Dynamic Registration
These OPs MUST support Dynamic Client Registration, as defined in [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-core-1_0.html#OpenID.Registration) [OpenID.Registration].
UserInfo Endpoint
All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint, as defined in [Section 5.3](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). (Self-Issued OPs do not issue Access Tokens.)
Public Keys Published as Bare Keys
These OPs MUST publish their public keys as bare JWK keys (which MAY also be accompanied by X.509 representations of those keys).
Request URI
These OPs MUST support requests made using a Request Object value that is retrieved from a Request URI that is provided with the request_uri parameter, as defined in [Section 6.2](https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter).

[muhlemmer]

See this discussion for a proposal wrt key management:

• #7464

[livio-a]

closing in favor of the discussion mentioned above