Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 20:42:33 +0200] rev 5435
mod_rest/rest.sh: Add --logout to revoke token
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 20:41:35 +0200] rev 5434
mod_rest/rest.sh: Make scopes to request configurable in restrc
Makes it easier to experiment with requesting various scopes and roles
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 20:25:18 +0200] rev 5433
mod_http_oauth2: Strip unknown scopes from consent page
Since the scope string can be any arbitrary space-separated strings.
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 20:24:18 +0200] rev 5432
mod_http_oauth2: Simplify code with the power of first class functions
Selected / primary role is the first assumable role
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 19:11:20 +0200] rev 5431
mod_http_oauth2: More functional functions
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 19:07:52 +0200] rev 5430
mod_http_oauth2: Add function for filtering roles
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 19:29:15 +0200] rev 5429
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.
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 19:40:57 +0200] rev 5428
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.
Kim Alvefur <zash@zash.se> [Sun, 07 May 2023 19:06:37 +0200] rev 5427
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.
Kim Alvefur <zash@zash.se> [Sat, 06 May 2023 17:06:13 +0200] rev 5426
mod_block_registrations: Refresh Compatibility section
Update to use currently supported Prosody versions.
Kim Alvefur <zash@zash.se> [Sat, 06 May 2023 17:04:28 +0200] rev 5425
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.
Kim Alvefur <zash@zash.se> [Sat, 06 May 2023 12:23:22 +0200] rev 5424
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
Kim Alvefur <zash@zash.se> [Fri, 05 May 2023 21:32:34 +0200] rev 5423
mod_http_oauth2: Fix error if no scopes requested
granted_scopes would be nil but the later code expects an array
Kim Alvefur <zash@zash.se> [Fri, 05 May 2023 01:23:13 +0200] rev 5422
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.
Kim Alvefur <zash@zash.se> [Fri, 05 May 2023 00:57:20 +0200] rev 5421
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.
Kim Alvefur <zash@zash.se> [Thu, 04 May 2023 18:41:33 +0200] rev 5420
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.
Kim Alvefur <zash@zash.se> [Wed, 03 May 2023 10:55:22 +0200] rev 5419
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.
Kim Alvefur <zash@zash.se> [Wed, 03 May 2023 10:54:15 +0200] rev 5418
mod_strict_https: Refresh README
Kim Alvefur <zash@zash.se> [Wed, 03 May 2023 10:34:00 +0200] rev 5417
mod_prometheus: Wrap pointer to mod_http_openmetrics in a box
Kim Alvefur <zash@zash.se> [Wed, 03 May 2023 10:29:46 +0200] rev 5416
mod_listusers: Obsolete, suggest prosodyctl shell instead
Kim Alvefur <zash@zash.se> [Wed, 03 May 2023 10:16:15 +0200] rev 5415
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 19:06:17 +0200] rev 5414
mod_http_oauth2: Link to RFC 7009: OAuth 2.0 Token Revocation
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 17:04:19 +0200] rev 5413
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 17:01:02 +0200] rev 5412
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:39:32 +0200] rev 5411
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:34:31 +0200] rev 5410
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:31:25 +0200] rev 5409
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.
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:23:40 +0200] rev 5408
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
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:23:05 +0200] rev 5407
mod_http_oauth2: Simplify validation of various URIs
Why: diffstat
How: Reuse of the redirect_uri_allowed() function
Kim Alvefur <zash@zash.se> [Tue, 02 May 2023 16:22:17 +0200] rev 5406
mod_http_oauth2: More appropriate error conditions in client validation
Specified in RFC7591 for these kinds of issues.