docs(registry/coder/modules/jfrog-oauth): clarify JFrog SaaS and self-hosted OAuth setup

[matifali]

Problem

The JFrog OAuth module README said it was only "usable by JFrog self-hosted (on-premises) Artifactory," which gave mixed signals. The module also works with JFrog SaaS, and a customer asked for clearer setup instructions since they only have a production SaaS instance to test against.

Fix

• State the module works with both JFrog SaaS and self-hosted (on-premises) Artifactory.
• Add a Setup section with explicit steps for both, including the SaaS Custom Integration path, redirect URI, scope, and the CODER_EXTERNAL_AUTH_* configuration.
• Update stale docs/v2/latest links to current paths.

No version bump: documentation-only change per the registry versioning guidelines.

Note

The same misleading sentence also exists in the Coder docs guide (docs/admin/integrations/jfrog-artifactory.md in coder/coder). This PR fixes only the registry module README per REG-73. A follow-up against coder/coder will fix the guide.

Closes REG-73

🤖 Generated with Claude Code

🤖 This PR was created with the help of Coder Agents, and needs a human review. 🧑‍💻

[linear-code]

REG-73

[github-actions]

Module Scorecard Check

coder/jfrog-oauth: 68 → 85

✅ Score improvement: 68 → 85 (+17).

Theme	Before	After
Presentation & Onboarding	21 / 25	17 / 25
Integration	—	—
Credential Hygiene	18 / 20	20 / 20
Restricted-Environment	2 / 20	17 / 20
Engineering Quality	10 / 10	10 / 10
Overall	68 / 100	85 / 100

Full scorecard for this PR

Presentation & Onboarding	Credential Hygiene	Restricted-Environment Readiness	Engineering Quality	Overall
17 / 25	20 / 20	17 / 20	10 / 10	85 / 100

Drilldown

Presentation & Onboarding — 17 / 25

Criterion	Max	Score	Notes
Configuration-mode examples	12	12	Multiple documented examples covering npm, pypi, go, docker, conda, maven package managers; code-server integration example; using access token in other resources. Each major mode (different package manager combinations) has sensible defaults.
Coder-context framing	8	5	README explains OAuth flow via Coder external-auth and mentions JFrog CLI installation, but lacks clarity on where Coder fits in the overall workflow. The integration setup is documented but the value-add over direct JFrog usage is not clearly articulated.
Visual preview	5	0	README references  but the actual image file is not included in the module files provided.

Credential Hygiene — 20 / 20

Criterion	Max	Score	Notes
Secrets marked sensitive	16	16	access_token output is marked sensitive = true. README examples use OAuth flow via external-auth; no inline secrets in examples. All credential handling goes through data.coder_external_auth.jfrog.access_token.
Non-hardcoded auth path	4	4	Uses Coder external-auth OAuth flow. README documents complete setup with JFrog application integration and Coder external auth provider. No API keys pasted into templates.

Restricted-Environment Readiness — 17 / 20

Criterion	Max	Score	Notes
Mirrorable artifact source	10	0	The JFrog CLI is downloaded from hardcoded https://install-cli.jfrog.io in run.sh with no module variable to override this URL. The module only allows skipping the download if jf is already installed, which is bring-your-own binary, not mirrorable source.
Bring-your-own binary	5	5	Documented in "Offline and air-gapped environments" section: "If jf is already on the PATH (for example, baked into your workspace image), the module detects it and skips the download." Script checks command -v jf before installing.
Egress transparency	3	3	Dedicated "External endpoints" section enumerates: https://install-cli.jfrog.io (conditional on CLI not installed) and the user's jfrog_url. Clear notes for restricted environments.
Runs without sudo	2	0	run.sh line 30: `curl -fL https://install-cli.jfrog.io

Engineering Quality — 10 / 10

Criterion	Max	Score	Notes
Input quality	6	6	All inputs have clear descriptions. jfrog_url has regex validation for http/https. username_field has validation for email/username. package_managers has detailed description with examples. Sensible defaults: username_field = "username", external_auth_id = "jfrog", configure_code_server = false, jfrog_server_id = "0".
Test coverage	4	4	Comprehensive .tftest.hcl with 11 test runs covering: required vars, empty/valid access tokens, URL validation, username_field validation, each package manager (npm, go, pypi, docker, conda, maven), code-server configuration, and GOPROXY env. Tests use override_data for external auth mocking and verify script content with assertions.

Overall — 85 / 100

Raw 64 / 75 → round(64 / 75 × 100) = 85

Track: Utility (auth/integration helper module)

Normalized from 75-point denominator (Utility modules skip track section).

---

Scored against SCORECARD.md with claude-sonnet-4-5. Language-model scores are advisory.

[matifali]

Addressed the valid scorecard items in d48fde3 (README-scoped):

• Coder-context framing / non-hardcoded auth path: Added an intro paragraph explaining what the module adds on top of raw external-auth (installs jf, wires up package managers with each user's own OAuth token, no stored API keys or passwords).
• Bring-your-own binary: Documented that the module skips the download when jf is already on PATH.
• Egress transparency: Added a "JFrog CLI installation and offline use" section listing the external endpoints (install-cli.jfrog.io and jfrog_url) and air-gapped guidance.

Not addressed here (out of scope for a README change, tracking as follow-ups):

• Visual preview (0/5): false negative. The image exists at registry/coder/.images/jfrog-oauth.png; the scorecard only sees module files.
• Mirrorable artifact source (0/10): needs a new module input to override the JFrog CLI download URL. That's a feature + version bump + tests, so it belongs in its own PR.
• Test coverage (2/4): needs added tests, separate change.

🤖 This response was generated by Coder Agents.