mod_http_oauth2: Simplify code with the power of first class functions Selected / primary role is the first assumable role

mod_http_oauth2: More functional functions

mod_http_oauth2: Add function for filtering roles

mod_http_oauth2: Support granting zero role-scopes It seems Very Bad that if you uncheck all roles on the consent page, you get the default scopes, which seems the opposite of what you probably intended. Currently, mod_tokenauth will do the same thing, so work is needed there too to allow issuing tokens without roles. A token without a role could be used for OIDC login, and not much else. This seems like a valuable thing to support.

mod_http_oauth2: Revert role selector, going to try something else Back out f2c7bb3af600 Allowing only a single role to be encoded into the grant takes away the possibility of having multiple roles in the grant, one of which is selected when issuing an access token. It also takes away the ability to have zero roles granted, which could be useful e.g. when you only need OIDC scopes.

mod_http_oauth2: Include all granted roles in scopes The client is allowed to request a subset of granted scopes, so it makes sense to record all granted roles so that another could be selected at access token issuance.

mod_block_registrations: Refresh Compatibility section Update to use currently supported Prosody versions.

mod_block_registrations: Update description expansion of default list The default got a lot longer in 368bf9b06484, a bit too long to fit comfortably in this table.

mod_http_oauth2: Bail out of implicit flow on invalid or missing redirect Probably hasn't been tested, and maybe never will since it's disabled and more or less deprecated in OAuth 2.1

mod_http_oauth2: Fix error if no scopes requested granted_scopes would be nil but the later code expects an array

mod_http_oauth2: Add role selector to consent page List includes all roles available to the user, if more than one. Defaults to either the first role in the scope string or the users primary role. Earlier draft listed all roles, but having options that can't be selected is bad UX and the entire list of all roles on the server could be long, and perhaps even sensitive. Allows e.g. picking a role with fewer permissions than what might otherwise have been selected. UX wise, doing this with more checkboxes or possibly radio buttons would have been confusion and/or looked messier. Fixes the previous situation where unselecting a role would default to the primary role, which could be more permissions than requested.

mod_http_oauth2: Refactor scope handling into smaller functions Goal is to put a dropdown on the consent page with your allowed roles. Smaller functions make it easier to reuse. Readability may be improved slightly as well.

mod_http_oauth2: Add option for specifying TTL of registered clients Meant to simplify configuration, since TTL vs ignoring expiration is expected to be the main thing one would want to configure. Unsure what the implications of having unlimited lifetime of clients are, given no way to revoke them currently, short of rotating the signing secret. On one hand, it would be annoying to have the client expire. On the other hand, it is trivial to re-register it.

mod_strict_https: Add way to disable redirect Since Prosody 0.12+ does not listen on unencrypted http anymore, this is likely to cause trouble. Especially since the URL construction is problematic and awkward.

mod_strict_https: Refresh README

mod_prometheus: Wrap pointer to mod_http_openmetrics in a box

mod_listusers: Obsolete, suggest prosodyctl shell instead

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?