mod_strict_https: Update to use modern APIs instead of monkey patching Updates one of the least recently updated modules :) Mapping HTTP Host to Prosody host remains awkward.

mod_http_oauth2: Link to RFC 7009: OAuth 2.0 Token Revocation

mod_http_oauth2: Add service documentation URL to metadata This is aimed to those building integrations, so the modules site seems appropriate. Configurable so that a deployment can point to their own OAuth documentation.

mod_http_oauth2: Allow configuring links to policy and terms in metadata These are for the Authorization Server, here the same as the XMPP server.

mod_http_oauth2: Don't issue client_secret when not using authentication This is pretty much only for implicit flow, which is considered insecure anyway, so this is of limited value. If we delete all the implicit flow code, this could be reverted.

mod_http_oauth2: Validate consistency of response and grant types Ensure that these correlated fields make sense per RFC 7591 § 2.1, even though we currently only check the response type during authorization. This could probably all be deleted if (when!) we remove the implicit grant, since then these things don't make any sense anymore.

mod_http_oauth2: Enforce response type encoded in client_id The client promises to only use this response type, so we should hold them to that. This makes it fail earlier if the response type is disabled or the client is trying to use one that it promised not to use. Better than failing after login and consent.

mod_http_oauth2: Strip unknown extra fields from client registration We shouldn't sign things we don't understand! RFC 7591 section-2 states: > The authorization server MUST ignore any client metadata sent by the > client that it does not understand (for instance, by silently removing > unknown metadata from the client's registration record during > processing). Prevents grandfathering in of unvalidated data that might become used later, especially since the 'additionalProperties' schema keyword was removed in 698fef74ce53

mod_http_oauth2: Simplify validation of various URIs Why: diffstat How: Reuse of the redirect_uri_allowed() function

mod_http_oauth2: More appropriate error conditions in client validation Specified in RFC7591 for these kinds of issues.

mod_http_oauth2: Reject loopback URIs as client_uri This really should be a proper website with info, https://localhost is not good enough. Ideally we'd validate that it's got proper DNS and is actually reachable, but triggering HTTP or even DNS lookups seems like it would carry abuse potential that would best to avoid.

mod_http_oauth2: Reduce line count of metadata construction More compact and readable than long if-then chains

mod_http_oauth2: Advertise response modes Are you supposed to be able to influence these somewhere, or is this just response types with different labels?

mod_http_oauth2: Advertise supported grant types Seems redundant, since it's just the response types with other labels.

mod_http_oauth2: Advertise revocation endpoint in metadata How were you supposed to know this was supported otherwise? It support Basic auth and ... none?

mod_http_oauth2: Return status 405 for GET to endpoints without GET handler Endpoints that only do POST have the weird side effect that a GET query to them return 404, which doesn't quite feel like the right semantics.

mod_inotify_reload: Update to use FD watching method This removes the need to present a fake socket interface, simplifying everything.

mod_http_oauth2: Allow loopback IP literals in redirect URIs Previously only exactly "http://localhost" was allowed, but RFC 8252 seems to recommend both ::1 and 127.0.0.1 be allowed.

mod_http_oauth2: Add way to retrieve registration schema Mostly for convenience and to fill the void otherwise and drive the awkward fallback to 404 away.

mod_http_oauth2: Fix missing base64 part of base64url (Thanks KeyCloak) Obligatory bugs in untested code.

mod_http_oauth2: Fix accidental uppercase in invocation of hash function Thanks auto-complete!

mod_http_oauth2: Advertise the currently supported id_token signing algorithm This field is REQUIRED. The algorithm RS256 MUST be included, but isn't because we don't implement it, as that would require implementing a pile of additional cryptography and JWT stuff. Instead the id_token is signed using the client secret, which allows verification by the client, since it's a shared secret per OpenID Connect Core 1.0 § 10.1 under Symmetric Signatures. OpenID Connect Discovery 1.0 has a lot of REQUIRED and MUST clauses that are not supported here, but that's okay because this is served from the RFC 8414 OAuth 2.0 Authorization Server Metadata .well-known endpoint!

mod_http_oauth2: Specify that 'contacts' items are emails in client registration Not enforced, but good for documentation. > Array of strings representing ways to contact people responsible for > this client, typically email addresses. "typically" isn't a great word in a specification, so one could persume this may be e.g. URLs like https://example.com/contact-us or so as well.

Back out 6f13200c9fc1: Confused request URI with redirect URI redirect_uris is already marked as required in RFC7591

mod_rest/rest.sh: Implement RFC 7636 PKCE with the 'plain' method The S256 code challenge method left as a future exercise.

mod_http_oauth2: Advertise required registration of redirect URIs Specified in OpenID Connect Discovery 1.0 Seems important to be aware of when registering a client.

mod_http_oauth2: Advertise supported token endpoint auth methods

mod_http_oauth2: Allow configuring PKCE challenge methods You'd pretty much only want this to disable the 'plain' method, since it doesn't seem to add that much security?

mod_http_oauth2: Implement RFC 7628 Proof Key for Code Exchange Likely to become mandatory in OAuth 2.1. Backwards compatible since the default 'plain' verifier would compare nil with nil if the relevant parameters are left out.

mod_http_oauth2: Reorder routes into order they happen in OAuth 2.0 Since I usually start here to remember the order of things, might as well turn it into a mini step by step guide :)