Implement authentication with Okta SSO - #284
Conversation
The Marketing Guru — Round 1 ReviewVerdict: REQUEST_CHANGES Exact test command passed: I do not recommend a totally different product path. Enterprise SSO is the right path for this requirement. The implementation is not ready because the public-facing docs are incomplete and the PR skips required release communication. Required fixes:
|
The Architect — Round 1 ReviewVerdict: REQUEST_CHANGES Passed locally with exact command: I do not recommend throwing this away, but the skipped plan review shows. The implementation treats Express HTTP auth as whole-service auth. It is not. Fix the coherence holes before shipping. Required changes:
No totally different path is required. A reverse-proxy-only Okta approach would have been the simpler plan for internal deployment, but this PR can ship if it actually gates every access path and documents/tests the contract it introduces. |
The Craftsperson — Round 1 ReviewVerdict: REQUEST_CHANGES Tests: I do recommend a different path for the Okta half of this implementation: do not ship a mostly untested, hand-rolled OIDC flow. Either keep this PR to the reverse-proxy/trusted-header integration, or put the Okta code behind a small auth-client port implemented with a maintained OIDC library and behavior-tested at the HTTP boundary. Required fixes:
This has not completed red-green-refactor. The shape is still "make it work" code with tests added around the easiest pure helpers, not tests that drove the design of the auth behavior. |
The Minimalist — Round 1 ReviewVerdict: REQUEST_CHANGES Test command passed: I recommend a different path. This skipped plan review and went straight to 150 lines of hand-rolled OAuth/session code. For an internal enterprise deployment, the simpler design is: let Okta/SSO live at the edge (Okta Access Gateway, oauth2-proxy, corporate reverse proxy, etc.) and make Remarq enforce one trusted identity header. That deletes Blocking issues:
Fix: delete the direct Okta flow unless there is a concrete reviewed requirement for Remarq to own OAuth. Implement the smaller edge-auth path and apply it consistently to HTTP and WebSocket upgrades. If direct OAuth stays, come back with a plan-reviewed design and integration tests covering the real mounted routes and |
The Steward — Round 1 ReviewVerdict: REQUEST_CHANGES Test command passed: I fetched/read the diff with I do not recommend a totally different path. App-level Okta plus trusted-header mode is a viable path. This implementation is not production-ready. Required fixes:
|
The Marketing Guru — Round 2 ReviewVerdict: REQUEST_CHANGES Exact test command passed: I fetched and read the current PR diff. I do not recommend a totally different path from the Marketing Guru lens; enterprise auth is still the right story. But the public docs still make promises the implementation does not keep. Required fixes:
These are documentation contract issues, not copy polish. The right thing must be easy for operators; right now the guide sends them to endpoints whose behavior differs from the docs. |
The Craftsperson — Round 2 ReviewVerdict: REQUEST_CHANGES Exact test command passed: I fetched/read the current PR diff and changed files ( Round 2 fixed the obvious boundary gaps: auth now runs before JSON parsing and Blocking issues:
This is still a red-green-refactor issue, not a request for more coverage percentage. The tests cover the easiest helpers and two boundary failures; they still do not document the successful session design that future refactors must preserve. |
The Minimalist — Round 2 ReviewVerdict: REQUEST_CHANGES Exact test command passed on retry: I fetched/read the current PR diff and changed files with I still think the simpler long-term shape is edge Okta + one trusted identity header. But given the issue explicitly asks for a functional Okta SSO flow, I am not blocking on a total rewrite in Round 2. If Remarq owns OAuth/session state, the code and tests have to stay boring and reliable. Blocking issues:
|
The Architect — Round 2 ReviewVerdict: APPROVE Exact test command passed: I fetched and read the current PR diff and changed files. CI is green. I also manually verified the Okta callback happy path against a fake Okta server: No totally different path is warranted now. Reverse-proxy-only auth is still the smaller architecture, but issue #275 explicitly asks for an Okta SSO flow. The PR now holds together: auth is mounted before JSON parsing, WebSocket upgrades use the same auth decision, config failures fail closed with actionable errors, sessions expire, and the public API/docs surface includes the new auth endpoints. Round 1's material coherence holes are resolved. Remaining cleanup is not worth another review loop: Ship it. |
The Steward — Round 2 ReviewVerdict: REQUEST_CHANGES Exact test command passed on rerun: I fetched and read the current PR diff and changed files. I still do not recommend throwing this away: app-level Okta plus trusted-header mode can be a viable path. Round 2 fixed the largest runtime holes from my Round 1 review: auth now runs before JSON parsing, WebSocket upgrades use the same auth decision, and Okta calls are bounded by a timeout. I am still blocking on production/API-contract issues:
One non-blocking observation: the first run of the exact test command failed in |
What changed
Implemented enterprise authentication support with Okta authorization-code SSO, session cookies, configurable timeout, trusted-auth-header mode, and operator docs.
Why
Closes #275. Block Security requires no anonymous access, Okta SSO, and expiring sessions before internal integration.
New/Changed Endpoints
GET/loginGET/auth/callbackremarq_session.How to verify
npm run checkREMARQ_AUTH_REQUIRED=trueplusOKTA_*vars and verify anonymous API requests return401.Manual testing checklist
npm run start)npm test)