zitadel/internal/api/oidc/integration_test/keys_test.go

122 lines
3.6 KiB
Go
Raw Normal View History

feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
//go:build integration
package oidc_test
import (
"crypto/rsa"
"encoding/json"
"net/http"
"testing"
"time"
"github.com/go-jose/go-jose/v4"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
"github.com/zitadel/oidc/v3/pkg/client"
"github.com/zitadel/oidc/v3/pkg/oidc"
"google.golang.org/protobuf/proto"
http_util "github.com/zitadel/zitadel/internal/api/http"
"github.com/zitadel/zitadel/internal/crypto"
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
"github.com/zitadel/zitadel/internal/integration"
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
"github.com/zitadel/zitadel/pkg/grpc/feature/v2"
oidc_pb "github.com/zitadel/zitadel/pkg/grpc/oidc/v2"
)
func TestServer_Keys(t *testing.T) {
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
instance := integration.NewInstance(CTX)
ctxLogin := instance.WithAuthorization(CTX, integration.UserTypeLogin)
clientID, _ := createClient(t, instance)
authRequestID := createAuthRequest(t, instance, clientID, redirectURI, oidc.ScopeOpenID, oidc.ScopeOfflineAccess, zitadelAudienceScope)
instance.RegisterUserPasskey(instance.WithAuthorization(CTX, integration.UserTypeOrgOwner), instance.AdminUserID)
sessionID, sessionToken, _, _ := instance.CreateVerifiedWebAuthNSession(t, ctxLogin, instance.AdminUserID)
linkResp, err := instance.Client.OIDCv2.CreateCallback(ctxLogin, &oidc_pb.CreateCallbackRequest{
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
AuthRequestId: authRequestID,
CallbackKind: &oidc_pb.CreateCallbackRequest_Session{
Session: &oidc_pb.Session{
SessionId: sessionID,
SessionToken: sessionToken,
},
},
})
require.NoError(t, err)
// code exchange so we are sure there is 1 legacy key pair.
code := assertCodeResponse(t, linkResp.GetCallbackUrl())
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
_, err = exchangeTokens(t, instance, clientID, code, redirectURI)
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
require.NoError(t, err)
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
issuer := http_util.BuildHTTP(instance.Domain, instance.Config.Port, instance.Config.Secure)
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
discovery, err := client.Discover(CTX, issuer, http.DefaultClient)
require.NoError(t, err)
tests := []struct {
name string
webKeyFeature bool
wantLen int
}{
{
name: "legacy only",
webKeyFeature: false,
wantLen: 1,
},
{
name: "webkeys with legacy",
webKeyFeature: true,
wantLen: 3, // 1 legacy + 2 created by enabling feature flag
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
ensureWebKeyFeature(t, instance, tt.webKeyFeature)
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
assert.EventuallyWithT(t, func(ttt *assert.CollectT) {
resp, err := http.Get(discovery.JwksURI)
require.NoError(ttt, err)
require.Equal(ttt, resp.StatusCode, http.StatusOK)
defer resp.Body.Close()
got := new(jose.JSONWebKeySet)
err = json.NewDecoder(resp.Body).Decode(got)
require.NoError(ttt, err)
assert.Len(t, got.Keys, tt.wantLen)
for _, key := range got.Keys {
_, ok := key.Key.(*rsa.PublicKey)
require.True(ttt, ok)
require.NotEmpty(ttt, key.KeyID)
require.Equal(ttt, key.Algorithm, string(jose.RS256))
require.Equal(ttt, key.Use, crypto.KeyUsageSigning.String())
}
cacheControl := resp.Header.Get("cache-control")
if tt.webKeyFeature {
require.Equal(ttt, "max-age=300, must-revalidate", cacheControl)
return
}
require.Equal(ttt, "no-store", cacheControl)
}, time.Minute, time.Second/10)
})
}
}
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
func ensureWebKeyFeature(t *testing.T, instance *integration.Instance, set bool) {
ctxIam := instance.WithAuthorization(CTX, integration.UserTypeIAMOwner)
_, err := instance.Client.FeatureV2.SetInstanceFeatures(ctxIam, &feature.SetInstanceFeaturesRequest{
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
WebKey: proto.Bool(set),
})
require.NoError(t, err)
t.Cleanup(func() {
chore(tests): use a coverage server binary (#8407) # Which Problems Are Solved Use a single server instance for API integration tests. This optimizes the time taken for the integration test pipeline, because it allows running tests on multiple packages in parallel. Also, it saves time by not start and stopping a zitadel server for every package. # How the Problems Are Solved - Build a binary with `go build -race -cover ....` - Integration tests only construct clients. The server remains running in the background. - The integration package and tested packages now fully utilize the API. No more direct database access trough `query` and `command` packages. - Use Makefile recipes to setup, start and stop the server in the background. - The binary has the race detector enabled - Init and setup jobs are configured to halt immediately on race condition - Because the server runs in the background, races are only logged. When the server is stopped and race logs exist, the Makefile recipe will throw an error and print the logs. - Makefile recipes include logic to print logs and convert coverage reports after the server is stopped. - Some tests need a downstream HTTP server to make requests, like quota and milestones. A new `integration/sink` package creates an HTTP server and uses websockets to forward HTTP request back to the test packages. The package API uses Go channels for abstraction and easy usage. # Additional Changes - Integration test files already used the `//go:build integration` directive. In order to properly split integration from unit tests, integration test files need to be in a `integration_test` subdirectory of their package. - `UseIsolatedInstance` used to overwrite the `Tester.Client` for each instance. Now a `Instance` object is returned with a gRPC client that is connected to the isolated instance's hostname. - The `Tester` type is now `Instance`. The object is created for the first instance, used by default in any test. Isolated instances are also `Instance` objects and therefore benefit from the same methods and values. The first instance and any other us capable of creating an isolated instance over the system API. - All test packages run in an Isolated instance by calling `NewInstance()` - Individual tests that use an isolated instance use `t.Parallel()` # Additional Context - Closes #6684 - https://go.dev/doc/articles/race_detector - https://go.dev/doc/build-cover --------- Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
2024-09-06 12:47:57 +00:00
_, err := instance.Client.FeatureV2.SetInstanceFeatures(ctxIam, &feature.SetInstanceFeaturesRequest{
feat(oidc): use web keys for token signing and verification (#8449) # Which Problems Are Solved Use web keys, managed by the `resources/v3alpha/web_keys` API, for OIDC token signing and verification, as well as serving the public web keys on the jwks / keys endpoint. Response header on the keys endpoint now allows caching of the response. This is now "safe" to do since keys can be created ahead of time and caches have sufficient time to pickup the change before keys get enabled. # How the Problems Are Solved - The web key format is used in the `getSignerOnce` function in the `api/oidc` package. - The public key cache is changed to get and store web keys. - The jwks / keys endpoint returns the combined set of valid "legacy" public keys and all available web keys. - Cache-Control max-age default to 5 minutes and is configured in `defaults.yaml`. When the web keys feature is enabled, fallback mechanisms are in place to obtain and convert "legacy" `query.PublicKey` as web keys when needed. This allows transitioning to the feature without invalidating existing tokens. A small performance overhead may be noticed on the keys endpoint, because 2 queries need to be run sequentially. This will disappear once the feature is stable and the legacy code gets cleaned up. # Additional Changes - Extend legacy key lifetimes so that tests can be run on an existing database with more than 6 hours apart. - Discovery endpoint returns all supported algorithms when the Web Key feature is enabled. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/8031 - Part of https://github.com/zitadel/zitadel/issues/7809 - After https://github.com/zitadel/oidc/pull/637 - After https://github.com/zitadel/oidc/pull/638
2024-08-23 12:43:46 +00:00
WebKey: proto.Bool(false),
})
require.NoError(t, err)
})
}