Token validation with multiple Identity Providers (or realms)

Document updated on Feb 20, 2023

The JWK aggregator plugin allows KrakenD to validate tokens issued by numerous Identity Providers or multiple realms of the same Identity Server. The JWK aggregator plugin allows KrakenD to validate tokens issued by numerous Identity Providers or multiple realms of the same Identity Server.

The default behavior of KrakenD allows you to validate JWT tokens using a single Identity Provider or tenant per endpoint. However, there are times when tokens arriving at an endpoint originate in different providers or different tenants or realms. This is especially true in multi-tenant scenarios, where an ongoing migration or other systems converge into the gateway. The KrakenD jwk-aggregator allows you to alleviate this issue. The default behavior of KrakenD allows you to validate JWT tokens using a single Identity Provider or tenant per endpoint. However, there are times when tokens arriving at an endpoint originate in different providers or different tenants or realms. This is especially true in multi-tenant scenarios, where an ongoing migration or other systems converge into the gateway. The KrakenD jwk-aggregator allows you to alleviate this issue.

The plugin appends all the keys found in the different origins and offers a unique URL, http://localhost:9876, that includes multiple sources. The plugin does not have any caching because endpoints do. The plugin appends all the keys found in the different origins and offers a unique URL, http://localhost:9876, that includes multiple sources. The plugin does not have any caching because endpoints do.

Configuration

The configuration is straightforward. You only need to include the following lines, where origins is the list of all possible public keys of your identity servers: The configuration is straightforward. You only need to include the following lines, where origins is the list of all possible public keys of your identity servers:

{
    "version": 3,
    "plugin": {
        "pattern":".so",
        "folder": "/opt/krakend/plugins/"
    },
    "extra_config": {
        "plugin/http-server": {
            "name": ["jwk-aggregator", "some-other-plugin-here" ],
            "jwk-aggregator":{
                "port": 9876,
                "origins":[
                    "https://provider1.tld/jwk.json",
                    "http://provider2/public_keys",
                    "https://keycloak/auth/realms/realm-first/protocol/openid-connect/certs",
                    "https://keycloak/auth/realms/realm-second/protocol/openid-connect/certs"
                    "https://provider1.tld/jwk.json",
                    "http://provider2/public_keys",
                    "https://keycloak/auth/realms/realm-first/protocol/openid-connect/certs",
                    "https://keycloak/auth/realms/realm-second/protocol/openid-connect/certs"
                    ]
            }
        }
    }
}

Endpoint’s configuration

In addition to the configuration above, the endpoints must point to the new service instead of a particular JWK URL. To do that, you have to reference it in the jwk_url as follows and set the disable_jwk_security flag to true (as the connection is internal and does not use TLS validation). You also need to enable cache to true to avoid hammering the aggregator on each request: In addition to the configuration above, the endpoints must point to the new service instead of a particular JWK URL. To do that, you have to reference it in the jwk_url as follows and set the disable_jwk_security flag to true (as the connection is internal and does not use TLS validation). You also need to enable cache to true to avoid hammering the aggregator on each request:

{
    "endpoint": "/protected/resource",
    "extra_config": {
        "auth/validator": {
            "alg": "RS256",
            "jwk_url": "http://localhost:9876",
            "disable_jwk_security": true,
            "cache": true
        }
    },
    "backend": [
        {
            "url_pattern": "/"
        }
    ]
}

And that’s all you need to support multiple identity providers’ origin! You can change the exposed port. There is no specific reason to keep the 9876.