Make use of the new vendor/core OAuth upstream module

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: This PR migrates the enterprise OAuth/OIDC flow to the new upstream sourcemeta::core::oauth module and removes the local header-only OAuth implementation.

Changes:

• Deletes enterprise/authentication/authentication_oauth.h and switches OIDC code to include <sourcemeta/core/oauth.h>
• Updates OIDC nonce generation to use oauth_random_token() (43-byte non-null-terminated token)
• Rebuilds the OIDC authorization URL using OAuthAuthorizationRequest + oauth_build_authorization_url()
• Updates the login endpoint to mint state and PKCE verifier via oauth_transaction_mint() and compute challenges via oauth_pkce_challenge()
• Updates the callback endpoint token exchange to use oauth_build_token_request_code() and oauth_client_secret_post()
• Adds sourcemeta::core::oauth to relevant CMake link dependencies for enterprise server/authentication targets

Technical Notes: The new OAuth helpers produce fixed-size 43-byte base64url tokens that must be handled using data()/size() (not C strings), and token request bodies are now built via the upstream form-encoding utilities.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

sourcemeta::core::SecureString body is immediately copied into a std::string for fetch.body(...), which defeats the wiping semantics and can leave client_secret/code_verifier in non-wiped memory longer than intended. If the intent is to keep secrets in wiping storage, this copy is a potential regression.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cubic-dev-ai]

1 issue found across 6 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="enterprise/server/include/sourcemeta/one/enterprise_server_action_auth_callback_v1.h">

<violation number="1" location="enterprise/server/include/sourcemeta/one/enterprise_server_action_auth_callback_v1.h:369">
P2: The `SecureString body` containing `client_secret` and `code_verifier` is immediately copied into a plain `std::string` here. This creates an unwiped copy on the regular heap, defeating the secure-wipe-on-destruct semantics that `SecureString` provides. If the intent of using `SecureString` is to limit how long secrets remain in memory, this conversion undoes that guarantee.

If `fetch.body()` cannot accept a `SecureString` directly, consider whether there's an overload or move-based path that avoids the unprotected copy, or document why the copy is acceptable in this context.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The SecureString body containing client_secret and code_verifier is immediately copied into a plain std::string here. This creates an unwiped copy on the regular heap, defeating the secure-wipe-on-destruct semantics that SecureString provides. If the intent of using SecureString is to limit how long secrets remain in memory, this conversion undoes that guarantee.

If fetch.body() cannot accept a SecureString directly, consider whether there's an overload or move-based path that avoids the unprotected copy, or document why the copy is acceptable in this context.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At enterprise/server/include/sourcemeta/one/enterprise_server_action_auth_callback_v1.h, line 369:

<comment>The `SecureString body` containing `client_secret` and `code_verifier` is immediately copied into a plain `std::string` here. This creates an unwiped copy on the regular heap, defeating the secure-wipe-on-destruct semantics that `SecureString` provides. If the intent of using `SecureString` is to limit how long secrets remain in memory, this conversion undoes that guarantee.

If `fetch.body()` cannot accept a `SecureString` directly, consider whether there's an overload or move-based path that avoids the unprotected copy, or document why the copy is acceptable in this context.</comment>

<file context>
@@ -360,9 +361,13 @@ class ActionAuthCallback_v1 : public sourcemeta::one::RouterAction {
+                                                       code_verifier, {}, body);
+      sourcemeta::core::oauth_client_secret_post(client_id, client_secret,
+                                                 body);
+      fetch.body(std::string{std::string_view{body}},
+                 "application/x-www-form-urlencoded");
       const auto result{fetch.send()};
</file context>

[github-actions]

Benchmark Index (community)

Details

Benchmark suite	Current: e4a7dc4	Previous: 6fb7969	Ratio
Add one schema (0 existing)	305 ms	302 ms	1.01
Add one schema (100 existing)	32 ms	26 ms	1.23
Add one schema (1000 existing)	94 ms	102 ms	0.92
Add one schema (10000 existing)	792 ms	1153 ms	0.69
Update one schema (1 existing)	22 ms	18 ms	1.22
Update one schema (101 existing)	31 ms	28 ms	1.11
Update one schema (1001 existing)	96 ms	86 ms	1.12
Update one schema (10001 existing)	802 ms	827 ms	0.97
Cached rebuild (1 existing)	8 ms	5 ms	1.60
Cached rebuild (101 existing)	10 ms	6 ms	1.67
Cached rebuild (1001 existing)	34 ms	19 ms	1.79
Cached rebuild (10001 existing)	287 ms	166 ms	1.73
Index 100 schemas	640 ms	632 ms	1.01
Index 1000 schemas	1456 ms	1153 ms	1.26
Index 10000 schemas	13750 ms	13800 ms	1.00
Index 10000 schemas (custom meta-schema)	16484 ms	16694 ms	0.99
Index 10000 schemas ($ref fan-out)	16722 ms	16103 ms	1.04

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions]

Benchmark Index (enterprise)

Details

Benchmark suite	Current: e4a7dc4	Previous: 6fb7969	Ratio
Add one schema (0 existing)	401 ms	397 ms	1.01
Add one schema (100 existing)	107 ms	105 ms	1.02
Add one schema (1000 existing)	157 ms	160 ms	0.98
Add one schema (10000 existing)	776 ms	767 ms	1.01
Update one schema (1 existing)	96 ms	97 ms	0.99
Update one schema (101 existing)	104 ms	101 ms	1.03
Update one schema (1001 existing)	160 ms	160 ms	1
Update one schema (10001 existing)	764 ms	781 ms	0.98
Cached rebuild (1 existing)	8 ms	8 ms	1
Cached rebuild (101 existing)	10 ms	10 ms	1
Cached rebuild (1001 existing)	31 ms	31 ms	1
Cached rebuild (10001 existing)	253 ms	251 ms	1.01
Index 100 schemas	720 ms	557 ms	1.29
Index 1000 schemas	1544 ms	1631 ms	0.95
Index 10000 schemas	13484 ms	13724 ms	0.98
Index 10000 schemas (custom meta-schema)	16990 ms	16454 ms	1.03
Index 10000 schemas ($ref fan-out)	16942 ms	17046 ms	0.99

This comment was automatically generated by workflow using github-action-benchmark.