From 7baefe80b6b00ec33dd2d33eda2e0a30adbe1ecd Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Mon, 10 Feb 2025 13:38:21 -0500 Subject: [PATCH 01/11] OpenIDConnect Policy RFC Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 181 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 181 insertions(+) create mode 100644 rfcs/0000-oidc-policy.md diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md new file mode 100644 index 0000000..590f85b --- /dev/null +++ b/rfcs/0000-oidc-policy.md @@ -0,0 +1,181 @@ +# `OpenIDConnectPolicy` - a metapolicy + +- Feature Name: oidc-policy +- Start Date: 2025-02-05 +- RFC PR: [Kuadrant/architecture#0114](https://github.com/Kuadrant/architecture/pull/114) +- Issue tracking: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/issues/0000) + +# Summary +[summary]: #summary + +The `OpenIDConnectPolicy` aims at helping users to easily & quickly get started with the Kuadrant stack to setup an +[OpenID Connect flow](https://openid.net/developers/how-connect-works/) without needing to initially understand how to +use Kuadrant's `AuthPolicy` to achieve their goals. + +# Motivation +[motivation]: #motivation + +There are a few goals this implementation hopes to achieve and set a precedent for introducing more such APIs in +Kuadrant: + + - users looking at an example policy would be able to make mostly sense of it without needing to lookup documentation; + - the policy would apply sensible defaults in most cases and only require the very minimal input from the user; + - the idea is to implement it as _metapolicy_, which would only be consumed by a controller to produce a `AuthPolicy` + that would then enforce the flow; + - it is _not_ the goal to expose all the power of the `AuthPolicy` to the user through the new policy, but rather to let + users achieve most of their goals by slowly exploring defaults of the policy and eventually dig down the stack, into + the `AuthPolicy` to expand their use cases when they need it; + - explore how to, overtime, grow the initial minimal API of the policy into a larger one to cover more use cases than + the one currently set as the goal for this RFC + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +The `OpenIDConnectPolicy` is a direct policy attachment that attaches to one or multiple +[`HttpRoute`](https://gateway-api.sigs.k8s.io/api-types/httproute/) objects. Targeted routes will require requests to +carry an access token to be authorized through. Should the token be missing or be invalid, the requesting entity gets +redirected to the `provider`'s `authorizationEndpoint` specified in the policy for them to identify. + +It is important to note here that the access token is to be negotiated stored by the client. While this may change in +the future, currently the token is to either be provided by the appropriate HTTP header (`Authorization: Bearer`, which +is the default source), or by a Cookie. + +## Minimal example + +Using a very minimal example, we'll use +[gitlab.com](https://docs.gitlab.com/ee/integration/openid_connect_provider.html) as our provider for an OpenID Connect +flow to protect all requests routed to our application by the `HttpRoute`. + +```yaml +apiVersion: kuadrant.io/v1alpha1 +kind: OpenIDConnectPolicy +metadata: + name: gitlab +spec: + targetRef: + name: toystore + group: gateway.networking.k8s.io + kind: HttpRoute + provider: + host: gitlab.com + credentials: + clientID: 35001bfef37042bf2fb125e9e8f99f0c719231632ab62a18cbf5220c3d1f8f10 +``` + +First we need to provide the `host` of our `provider`, in this case `gitlab.com`. Kuadrant will default to using +`https` to [query the provider for the additional metadata](https://datatracker.ietf.org/doc/html/rfc8414) it requires +from [gitlab's endpoing](https://gitlab.com/.well-known/openid-configuration), initially the `authorizationEndpoint` to which +to redirect unauthorized requests to. + +If the request for the additional metadata fails, all access to the protected resources will be `Unauthorized`. All the +information from the endpoint can be manually specified under `provider` to mitigate these failures. These values would +also override any values successfully obtained from querying the provider's endpoint. + +Next, we'll have to identify our request with the provider using the `clientID` that were +provided to us by, in this example, gitlab. You'd probably rather store these in a `credentialsRef` instead as we did +here. A `credentialsRef` would point to a Kubernetes' +[`Secret`](https://kubernetes.io/docs/concepts/configuration/secret/) with the required information. And that's all you +should need to get started with to use an OpenID Connect provider to authorize access to your application. + +## The complete `OpenIDConnectPolicy` + +Here is an example of the complete proposal for configuring an authorization flow using OpenID Connect: + +```yaml +apiVersion: kuadrant.io/v1alpha1 +kind: OpenIDConnectPolicy +metadata: + name: gitlab +spec: + targetRef: + name: toystore + group: gateway.networking.k8s.io + kind: HttpRoute + tokenSource: authorizationHeader + provider: + host: gitlab.com + discoveryEndpoint: https://gitlab.com/.well-known/openid-configuration + authorizationEndpoint: https://gitlab.com/oauth/authorize + authorizationEndpointPayload: + query: + client_id: provider.credentials.clientID + redirect_uri: >- route.gateway.listeners[0].hostname + "/oauth/callback" + scope: >- "openid" + response_type: >- "code" + tokenEndpoint: https://gitlab.com/oauth/token + introspectionEndpoint: https://gitlab.com/oauth/introspect + jwksUri: https://gitlab.com/oauth/discovery/keys + credentials: + clientID: 35001bfef37042bf2fb125e9e8f99f0c719231632ab62a18cbf5220c3d1f8f10 + clientSecret: gloas-35001bfef37042bf2fb125e9e8f99f0c719231632ab62a18cbf5220c3d1f8f10 + redirectUri: + host: example.org + path: /oauth/callback +``` + +Some of these were inferred in the simple example above, while others are implied and some not even necessary for the +basic case. `tokenEndpoint` and `introspectionEndpoint` are both unnecessary for this flow to succeed. That's because we +use the `authorizationHeader` as the source for our access token. In this flow, we let the client deal with getting the +token from the identity provider, i.e. gitlab, as well as storing it and sending it along each request to our +application. + +While we do need the `authorizationEndpoint` to redirect unauthorized requests to the identity provider, as well as the +`jwksUri` to validate the token when one is present, these can be inferred from the `host` by querying the +`discoveryEndpoint` from the provider, which itself is inferred from the `host`. + +Kuadrant will also automatically append a query string to the `authorizationEndpoint` when forwarding a user. That will +contain data inferred from the configuration itself, as well as some defaults: + + - `client_id`: from the `provider`'s `credential` section + - `redirect_uri`: composed of `host`, inferred if there is a single listener for the `Gateway` the targeted `HttpRoute` + is pointed to; and the `path`, which defaults to `/oauth/callback` + - `scope`: defaults to `openid` + - `response_type`: defaulting to `code` + + All of which can be overridden by explicitly configuring the `authorizationEndpointPayload` explicitly. Any entry can + be added, the value needs to be a valid CEL expression and will be encoded depending on the how the payload is to be + sent. Here `query`, each key/value pair will be URL encoded and appended to the `authorizationEndpoint` when + redirecting. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +### WIP + +Some of this I think I have sorted out in a proof of concept... But I'm not completely done yet. +I'm trying to see if I can get away with: + - Having the client completely deal with `401 Unauthorized` and have it initiate the flow; + - Having the client intercept the redirect when being redirected from the Identity Provider, rather than needing to + have the `AuthConfig` deal with it so that the flow is completely handled by the client. + +I'm doing this by using the information provided here and using it inside the `AuthPolicy` directly for now. All that +then remains is writing the mapper controller for "translating" the `OpenIDConnectPolicy` into an `AuthPolicy`. + +# Drawbacks +[drawbacks]: #drawbacks + + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + + - This iteration is fairly low risk. It tries to make this all work with multiple OIDC providers, starting with Gitlab. + - Today, no changes are required to `AuthorizationPolicy` or `Authorino` nor any other component in Kuadrant, this only + does some to the heavy lifting for the users. + - The API leaves some space to grow it more complex use cases as we evolve this to support possibly more advanced + use cases. + +# Prior art +[prior-art]: #prior-art + + - I'm looking into some OIDC client & server side libraries to see how to best shape the API. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + + +# Future possibilities +[future-possibilities]: #future-possibilities + + - Add support for letting the upstream deal with the token exchange? + - Add support for letting Kuadrant (i.e. Authorino?) exchange the token with the Identity Provider and store it? + From 2a409b5b37fcb2d455bd0cb4c5f794ee8c8baaeb Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Mon, 10 Feb 2025 14:33:24 -0500 Subject: [PATCH 02/11] Fix yaml Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 590f85b..5eec01e 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -99,9 +99,11 @@ spec: authorizationEndpointPayload: query: client_id: provider.credentials.clientID - redirect_uri: >- route.gateway.listeners[0].hostname + "/oauth/callback" - scope: >- "openid" - response_type: >- "code" + redirect_uri: route.gateway.listeners[0].hostname + "/oauth/callback" + scope: |- + "openid" + response_type: |- + "code" tokenEndpoint: https://gitlab.com/oauth/token introspectionEndpoint: https://gitlab.com/oauth/introspect jwksUri: https://gitlab.com/oauth/discovery/keys From b98f83a71f08d7b644d036b0b3b8248dab0cfe5e Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Tue, 11 Feb 2025 11:00:30 -0500 Subject: [PATCH 03/11] s/HttpRoute/HTTPRoute/g Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 5eec01e..1689c00 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -32,7 +32,7 @@ Kuadrant: [guide-level-explanation]: #guide-level-explanation The `OpenIDConnectPolicy` is a direct policy attachment that attaches to one or multiple -[`HttpRoute`](https://gateway-api.sigs.k8s.io/api-types/httproute/) objects. Targeted routes will require requests to +[`HTTPRoute`](https://gateway-api.sigs.k8s.io/api-types/httproute/) objects. Targeted routes will require requests to carry an access token to be authorized through. Should the token be missing or be invalid, the requesting entity gets redirected to the `provider`'s `authorizationEndpoint` specified in the policy for them to identify. @@ -44,7 +44,7 @@ is the default source), or by a Cookie. Using a very minimal example, we'll use [gitlab.com](https://docs.gitlab.com/ee/integration/openid_connect_provider.html) as our provider for an OpenID Connect -flow to protect all requests routed to our application by the `HttpRoute`. +flow to protect all requests routed to our application by the `HTTPRoute`. ```yaml apiVersion: kuadrant.io/v1alpha1 @@ -55,7 +55,7 @@ spec: targetRef: name: toystore group: gateway.networking.k8s.io - kind: HttpRoute + kind: HTTPRoute provider: host: gitlab.com credentials: @@ -90,7 +90,7 @@ spec: targetRef: name: toystore group: gateway.networking.k8s.io - kind: HttpRoute + kind: HTTPRoute tokenSource: authorizationHeader provider: host: gitlab.com @@ -129,7 +129,7 @@ Kuadrant will also automatically append a query string to the `authorizationEndp contain data inferred from the configuration itself, as well as some defaults: - `client_id`: from the `provider`'s `credential` section - - `redirect_uri`: composed of `host`, inferred if there is a single listener for the `Gateway` the targeted `HttpRoute` + - `redirect_uri`: composed of `host`, inferred if there is a single listener for the `Gateway` the targeted `HTTPRoute` is pointed to; and the `path`, which defaults to `/oauth/callback` - `scope`: defaults to `openid` - `response_type`: defaulting to `code` From 89277daec19d62cef9b70265b59236ac0382a47c Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Tue, 11 Feb 2025 11:03:57 -0500 Subject: [PATCH 04/11] Added authz to future options? Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 1689c00..825dc16 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -180,4 +180,6 @@ then remains is writing the mapper controller for "translating" the `OpenIDConne - Add support for letting the upstream deal with the token exchange? - Add support for letting Kuadrant (i.e. Authorino?) exchange the token with the Identity Provider and store it? + - Investigate how to expand on the authorization aspect: either by composing with another resource, expanding that one, + leveraging defaults & overrides, have the user fix it a the `AuthPolicy` layer themselves, ... ? From f5ed708296533414ba95d6c700c26d6419c5aae3 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 12 Feb 2025 10:09:15 -0500 Subject: [PATCH 05/11] s/host/issuer/g Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 825dc16..d9ea07f 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -57,12 +57,12 @@ spec: group: gateway.networking.k8s.io kind: HTTPRoute provider: - host: gitlab.com + issuer: https://gitlab.com credentials: clientID: 35001bfef37042bf2fb125e9e8f99f0c719231632ab62a18cbf5220c3d1f8f10 ``` -First we need to provide the `host` of our `provider`, in this case `gitlab.com`. Kuadrant will default to using +First we need to provide the `issuer` of our `provider`, in this case `gitlab.com`. Kuadrant will default to using `https` to [query the provider for the additional metadata](https://datatracker.ietf.org/doc/html/rfc8414) it requires from [gitlab's endpoing](https://gitlab.com/.well-known/openid-configuration), initially the `authorizationEndpoint` to which to redirect unauthorized requests to. @@ -93,7 +93,7 @@ spec: kind: HTTPRoute tokenSource: authorizationHeader provider: - host: gitlab.com + issuer: https://gitlab.com discoveryEndpoint: https://gitlab.com/.well-known/openid-configuration authorizationEndpoint: https://gitlab.com/oauth/authorize authorizationEndpointPayload: @@ -122,8 +122,8 @@ token from the identity provider, i.e. gitlab, as well as storing it and sending application. While we do need the `authorizationEndpoint` to redirect unauthorized requests to the identity provider, as well as the -`jwksUri` to validate the token when one is present, these can be inferred from the `host` by querying the -`discoveryEndpoint` from the provider, which itself is inferred from the `host`. +`jwksUri` to validate the token when one is present, these can be inferred from the `issuer` by querying the +`discoveryEndpoint` from the provider, which itself is inferred from the `issuer`. Kuadrant will also automatically append a query string to the `authorizationEndpoint` when forwarding a user. That will contain data inferred from the configuration itself, as well as some defaults: From c1c1f8d85ddbf3db3c6749223e42b1e5e5529f39 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 12 Feb 2025 10:16:56 -0500 Subject: [PATCH 06/11] Rephrased some of the wording around fetching the metadata Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index d9ea07f..826faa3 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -62,9 +62,9 @@ spec: clientID: 35001bfef37042bf2fb125e9e8f99f0c719231632ab62a18cbf5220c3d1f8f10 ``` -First we need to provide the `issuer` of our `provider`, in this case `gitlab.com`. Kuadrant will default to using -`https` to [query the provider for the additional metadata](https://datatracker.ietf.org/doc/html/rfc8414) it requires -from [gitlab's endpoing](https://gitlab.com/.well-known/openid-configuration), initially the `authorizationEndpoint` to which +First we need to provide the `issuer` of our `provider`, in this case `https://gitlab.com`. Kuadrant will default +to [querying the provider for the additional metadata](https://datatracker.ietf.org/doc/html/rfc8414) it requires +from [gitlab's endpoint](https://gitlab.com/.well-known/openid-configuration), initially the `authorizationEndpoint` to which to redirect unauthorized requests to. If the request for the additional metadata fails, all access to the protected resources will be `Unauthorized`. All the From 7cc9be7828689fcf4b0474802f326e44263c2948 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 12 Feb 2025 13:40:18 -0500 Subject: [PATCH 07/11] Type Co-authored-by: Thomas Maas --- rfcs/0000-oidc-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 826faa3..aac81a7 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -25,7 +25,7 @@ Kuadrant: - it is _not_ the goal to expose all the power of the `AuthPolicy` to the user through the new policy, but rather to let users achieve most of their goals by slowly exploring defaults of the policy and eventually dig down the stack, into the `AuthPolicy` to expand their use cases when they need it; - - explore how to, overtime, grow the initial minimal API of the policy into a larger one to cover more use cases than + - explore how to, over time, grow the initial minimal API of the policy into a larger one to cover more use cases than the one currently set as the goal for this RFC # Guide-level explanation From 5215d7a0b8b3ff5e0517abe46b95c15be4fa2210 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 26 Feb 2025 09:14:00 -0500 Subject: [PATCH 08/11] Kuadrant to provide a better toolbox Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 35 ++++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index aac81a7..0f696e3 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -100,10 +100,8 @@ spec: query: client_id: provider.credentials.clientID redirect_uri: route.gateway.listeners[0].hostname + "/oauth/callback" - scope: |- - "openid" - response_type: |- - "code" + scope: openid + response_type: code tokenEndpoint: https://gitlab.com/oauth/token introspectionEndpoint: https://gitlab.com/oauth/introspect jwksUri: https://gitlab.com/oauth/discovery/keys @@ -131,8 +129,8 @@ contain data inferred from the configuration itself, as well as some defaults: - `client_id`: from the `provider`'s `credential` section - `redirect_uri`: composed of `host`, inferred if there is a single listener for the `Gateway` the targeted `HTTPRoute` is pointed to; and the `path`, which defaults to `/oauth/callback` - - `scope`: defaults to `openid` - - `response_type`: defaulting to `code` + - `scope`: defaults to `openid` (which is CEL context specific root binding, which itself defaults to the CEL value `"openid"`) + - `response_type`: defaulting to `code` (as above, a CEL context specific root binding, to `"code"`) All of which can be overridden by explicitly configuring the `authorizationEndpointPayload` explicitly. Any entry can be added, the value needs to be a valid CEL expression and will be encoded depending on the how the payload is to be @@ -142,7 +140,28 @@ contain data inferred from the configuration itself, as well as some defaults: # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -### WIP +## Dependencies +[dependencies]: #dependencies + +> [!warning] WIP +> This is still work in progress and is mostly blocked on the Kuadrant Open Architecture efforts. +> Below are the features needed to implement the above, which are expected to be provided by the underlying infrastructure. + +### CEL: Kuadrant specialized `Env` + +We would need a specialized [`Env`](https://github.com/google/cel-go/blob/v0.24.0/cel/env.go#L131-L158), i.e. customized +to each context that's defined in a CRD (e.g. a `OpenIDConnectProvider.AuthorizationEndpointPayload`) + +### Callback registration + +To provide a way to resolve default values, or validate user provided values to depend on Gateway API objects, the +actor handling the metapolicy would need to be informed of changes to the said objects. + +### A metapolicy registry + +A way to register the `OpenIDConnectPolicy` Kuadrant and/or the "metapolicy" controller + +## Other considerations Some of this I think I have sorted out in a proof of concept... But I'm not completely done yet. I'm trying to see if I can get away with: @@ -160,6 +179,8 @@ then remains is writing the mapper controller for "translating" the `OpenIDConne # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives + - While we could make this all work with a [Metacontroller](https://metacontroller.github.io/metacontroller/), either + one to control all metapolicies or one per metapolicy, without the infrastructure described in the [above dependencies](#dependencies). - This iteration is fairly low risk. It tries to make this all work with multiple OIDC providers, starting with Gitlab. - Today, no changes are required to `AuthorizationPolicy` or `Authorino` nor any other component in Kuadrant, this only does some to the heavy lifting for the users. From a1eae14989f41c751f6b9aa0af15903806cc4cf5 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 26 Feb 2025 09:16:20 -0500 Subject: [PATCH 09/11] GH formatting Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index 0f696e3..e15b153 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -143,7 +143,7 @@ contain data inferred from the configuration itself, as well as some defaults: ## Dependencies [dependencies]: #dependencies -> [!warning] WIP +> [!warning] > This is still work in progress and is mostly blocked on the Kuadrant Open Architecture efforts. > Below are the features needed to implement the above, which are expected to be provided by the underlying infrastructure. From d4e76c8fd1bf5679b0a525139f818afd0462e6da Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Wed, 26 Feb 2025 09:24:00 -0500 Subject: [PATCH 10/11] Rephrase the extension point Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index e15b153..bb3fa3d 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -159,7 +159,8 @@ actor handling the metapolicy would need to be informed of changes to the said o ### A metapolicy registry -A way to register the `OpenIDConnectPolicy` Kuadrant and/or the "metapolicy" controller +A way to register the `OpenIDConnectPolicy` with Kuadrant, or the "metapolicy" controller if we design it as an external +extension. ## Other considerations From bb29e44874e0d36b35739f3148cbedd02336a196 Mon Sep 17 00:00:00 2001 From: Alex Snaps Date: Tue, 4 Mar 2025 09:53:12 -0500 Subject: [PATCH 11/11] DAG query fns Signed-off-by: Alex Snaps --- rfcs/0000-oidc-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-oidc-policy.md b/rfcs/0000-oidc-policy.md index bb3fa3d..9c913b4 100644 --- a/rfcs/0000-oidc-policy.md +++ b/rfcs/0000-oidc-policy.md @@ -99,7 +99,7 @@ spec: authorizationEndpointPayload: query: client_id: provider.credentials.clientID - redirect_uri: route.gateway.listeners[0].hostname + "/oauth/callback" + redirect_uri: gatewaysFor(target)[0].listeners[0].hostname + "/oauth/callback" scope: openid response_type: code tokenEndpoint: https://gitlab.com/oauth/token