From 0685fdeee992d8ba7b58754a9c3e187cfa904c57 Mon Sep 17 00:00:00 2001 From: Michael Farrell Date: Fri, 21 Feb 2025 14:41:01 +1000 Subject: [PATCH] webfinger: remove some excess words, make things more consistent --- book/src/integrations/oauth2.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/book/src/integrations/oauth2.md b/book/src/integrations/oauth2.md index 656d9bd48..5c395293f 100644 --- a/book/src/integrations/oauth2.md +++ b/book/src/integrations/oauth2.md @@ -162,7 +162,7 @@ Token endpoint
-OpenID Connect issuer URI +OpenID Connect Issuer URL
@@ -462,7 +462,7 @@ Each client has unique signing keys and access secrets, so this is limited to ea entities at a well-known URL (`https://{hostname}/.well-known/webfinger`). It can be used by a WebFinger client to -[discover the OIDC issuer URL][webfinger-oidc] of an identity provider from the +[discover the OIDC Issuer URL][webfinger-oidc] of an identity provider from the hostname alone, and seems to be intended to support dynamic client registration flows for large public identity providers. @@ -473,17 +473,16 @@ is no guarantee that it is valid for any particular application protocol, unless an administrator explicitly provides for it. When setting up an application to authenticate with Kanidm, WebFinger **does not -add any security** over configuring an OpenID Discovery URL directly. In an OIDC +add any security** over configuring an OIDC Discovery URL directly. In an OIDC context, the specification makes a number of flawed assumptions which make it difficult to use with Kanidm: -* WebFinger assumes that the identity provider will give the same `iss` - (issuer) and OpenID Discovery document, including all URLs and signing keys, +* WebFinger assumes that an identity provider will use the same Issuer URL and + OIDC Discovery document (which contains endpoint URLs and token signing keys) for *all* OAuth 2.0/OIDC clients. - Kanidm uses *different* `iss` (issuer), signing keys, and some client-specific - endpoint URLs, which ensures that tokens can only be used with their intended - service. + Kanidm uses *client-specific* Issuer URLs, endpoint URLs and token signing + keys. This ensures that tokens can only be used with their intended service. * WebFinger endpoints must be served at the *root* of the domain of a user's SPN (ie: information about the user with SPN `user@idm.example.com` is at @@ -493,8 +492,8 @@ difficult to use with Kanidm: client ID in the request, so there is no way to tell them apart. As a result, Kanidm *does not* provide a WebFinger endpoint at its root URL, - because it could report an incorrect `iss` (issuer) and lead the client to an - incorrect OIDC discovery document. + because it could report an incorrect Issuer URL and lead the client to an + incorrect OIDC Discovery document. You will need a load balancer in front of Kanidm's HTTPS server to send a HTTP 307 redirect to the appropriate @@ -515,7 +514,7 @@ difficult to use with Kanidm: * Kanidm responds to *all* WebFinger queries with [an Identity Provider Discovery for OIDC URL][webfinger-oidc], **ignoring** - any supplied [`rel` parameter][webfinger-rel]. + [`rel` parameter(s)][webfinger-rel]. If you want to use WebFinger in any *other* context on Kanidm's hostname, you'll need a load balancer in front of Kanidm which matches on some property