mod_http_oauth2: Reject duplicate redirect URIs in registration

mod_http_oauth2: Fix schema to enforce at least one redirect URI minLength is for strings

mod_http_oauth2: Show only roles the user can use in consent dialog Confusing if it shows you roles you can't use.

mod_http_oauth2: Reference grant by id instead of value Fixes that the grant got mutated on use of refresh token, notably it would gain 'id' and 'jid' properties set there by mod_tokenauth. Previously also the secret token that we should not be remembering.

mod_http_oauth2: Scope FIXMEs

mod_http_oauth2: Describe type signatures of scope handling functions

mod_http_oauth2: Allow requesting a subset of scopes on token refresh This enables clients to request access tokens with fewer permissions than the grant they were given, reducing impact of token leak. Clients could e.g. request access tokens with some privileges and immediately revoke them after use, or other strategies.

mod_http_oauth2: Enforce client scope restrictions in authorization When registering a client, a scope field can be included as a promise to only ever use those. Here we enforce that promise, if given, ensuring a client can't request or be granted a scope it didn't provide in its registration. While currently there is no restrictions at registration time, this could be changed in the future in various ways.

mod_http_oauth2: Fix inclusion of role in refreshed access tokens `refresh_token_info` does not carry the role, and due to behavior prior to prosody trunk rev a1ba503610ed it would have reverted to the users' default role. After that it instead issues a token without role which is thus not usable with e.g. mod_rest

mod_http_oauth2: Fix unintentional persistence

mod_auth_oauth_external: Update compatibility section with unknowns The PLAIN bits may very well work, it just needs async support

mod_auth_oauth_external: Also do XEP-0106 escaping in SASL OAUTHBEARER For consistency. The mangling should be made configurable in the future.

mod_auth_oauth_external: Stub not implemented auth module methods Not providing some of these may trigger errors on use, which is something that would be nice to fix on the Prosody side, one day.

mod_auth_oauth_external: Add Mastodon to README

mod_auth_oauth_external: Allow different username in PLAIN vs final JID Mastodon for example having email addresses usernames in login, but a different username in the service itself. Thanks to @tcit@social.tcit.fr for the pointer to a usable validation endpoint for Mastodon, allowing this to be tested.

mod_auth_oauth_external: Remove untested JID mapping This should probably be opt-in.

mod_auth_oauth_external: Remove untested role mapping This ... broke things. If brought back, it would need additional validation.

mod_auth_oauth_external: Expect XEP-0106 escaped username in PLAIN This allows entering an email address as username in some clients by escaping the @ as \40, enabling authentication against Mastodon

mod_auth_oauth_external: Make 'scope' configurable in password grant request Needed by some OAuth servers, tested here with Mastodon

mod_auth_oauth_external: Add setting for client_secret Whether this is needed may vary by OAuth provider. Mastodon for example requires it.

mod_auth_oauth_external: Work without token validation endpoint In this mode, only PLAIN is possible and the provided username is assumed to be the XMPP localpart.

mod_auth_oauth_external: Fix missing import of util.jid

mod_rest/rest.sh: Trim trailing whitespace

mod_rest/rest.sh: Add --logout to revoke token

mod_rest/rest.sh: Make scopes to request configurable in restrc Makes it easier to experiment with requesting various scopes and roles

mod_http_oauth2: Strip unknown scopes from consent page Since the scope string can be any arbitrary space-separated strings.

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?

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.