Authentication API tests

The Identity Auth collection contains 66 sequential requests covering all 14 identity authentication endpoints, including expected failures. It uses Bruno's OpenCollection YAML format and the existing workspace.

The workspace also includes Doctor Auth: seven sequential requests for doctor login, verification, rejection cases and logout/revocation. Apply Identity and Doctor migrations, run go run ./tools/cli database seed --items doctors, then set Local's secret doctorPassword to doctor@doctor.com (or the seed's --password override). Run requests 01–07 once, in order. See Doctor authentication.

Run in Bruno

1. Start PostgreSQL, apply the identity migrations, and start the API. See the identity service setup. Keep the API terminal visible: the console email adapter prints verification and reset messages there.
2. Open bruno-api as a workspace (or open collections/identity-auth as a collection). Select the Local environment. Its baseUrl defaults to http://localhost:8080; change it if necessary.
3. In the Local environment editor, clear any old verificationToken and passwordResetToken values. Keep both marked secret. They are entered locally in Bruno; the tracked YAML contains only their names.
4. Run each numbered folder in order, with one iteration, sequentially. Finish each folder successfully before continuing. You can also send its individual requests in their numbered order. Keep the same collection open.

Folder	Requests	Action before continuing
01-account-and-profile	13	Copy the verification token into verificationToken.
02-verification-and-sessions	22	Continue to folder 03.
03-password-change-and-recovery	9	Copy the reset token into passwordResetToken.
04-password-reset-and-logout	22	All test sessions are revoked; clear the two email token secrets.

Manual token checkpoints: the last request in folder 01 sends the verification email, and the last request in folder 03 sends the password-reset email. Find the console JSON message addressed to this run's generated email; copy the raw value after Token: in its body, without quotes or API instructions. You can inspect the generated email in Bruno's runtime variables or the registration response. Do not use a token from a previous run or from the other test account.

Verification tokens expire after one hour; reset tokens expire after 30 minutes. Paste the token into the corresponding Local environment secret, save the environment, and then run the next folder. Access and refresh tokens are captured and chained automatically; you never need to paste those.

Do not use Run Collection for the normal manual workflow: there are two points where you must supply a token between folder runs. Missing tokens produce an explicit pre-request error. Prompt variables are deliberately avoided because Bruno skips requests containing them in its collection runner.

What the sequence verifies

Routes	Checks
POST register, POST login	Unique accounts, duplicate registration, short password, unknown account, login before verification, incorrect old passwords, updated credentials.
GET me, PUT me	Missing bearer, public user fields, persisted profile changes, clearing optional fields, invalid avatar URL, verification status.
POST email-verification, POST email-verification/confirm	Generic acknowledgement for known/unknown email, manual confirmation, one-time use, rejection of a password-reset token.
POST refresh	Rotation, new access token, replay detection, revocation of the entire replayed session, isolation of independent sessions.
GET sessions, DELETE sessions/{sessionId}	Multiple sessions, current-session flag, foreign-session ownership rejection, owned-session revocation and token invalidation.
PUT password	Incorrect current password, successful change, invalidation of access and refresh tokens, login with the new password.
POST password/forgot, POST password/reset	Generic known/unknown acknowledgement, invalid token, manual reset, one-time use, session invalidation, old-password rejection.
POST logout, POST logout-all	Single-session logout, idempotency, access/refresh invalidation, all-session logout, isolation of the other account.

All requests assert the exact HTTP status and Cache-Control: no-store. Error responses also check the problem response content type and status. Successful Success responses contain message, status_code, and data; acknowledgment actions return 200 with data: {}. Requests only advance the runtime authStep after every assertion passes; subsequent requests refuse to run out of order.

Reruns and troubleshooting

• Start at the first registration request in folder 01 for a fresh run. It resets runtime state and generates two unique @example.com accounts. Accounts remain in the database because the API has no account-deletion endpoint. A completed run revokes all of their sessions; an interrupted run may leave active sessions.
• Runtime credentials and the sequence counter belong to the open collection. Restarting Bruno loses that state; begin a fresh run rather than skipping ahead.
• When an assertion fails, stop and inspect the response. A failed request may already have changed server state. Restart from folder 01 after fixing the issue instead of replaying mutations or consumed tokens against the same account.
• Each complete run uses nine login attempts for the primary account, one for the second account, and one for a nonexistent address. It requests one verification email and one reset email per tested address. These stay within the service's current rate limits; repeated individual requests may not.
• A 503 can indicate unavailable auth dependencies; check the API startup and database configuration. A 429 usually means requests were repeated for the same account. A missing-token error means the environment secret is still empty.
• Use a development API. Keep real passwords and tokens out of request files. Exported Bruno reports/history can include credentials, so do not commit them.

CLI scope

The collection is intended for staged runs in the desktop client. With Bruno CLI 4.1.0 installed, the first folder can also be exercised independently:

cd bruno-api/collections/identity-auth
bru run 01-account-and-profile --env Local --bail

Separate CLI invocations do not share runtime variables, so running folders 02–04 in new CLI processes will fail their sequence guards. This collection does not include automatic log scraping or a server endpoint for retrieving email tokens.

Validation

Validated with Bruno CLI 4.1.0 against the real API and an isolated PostgreSQL database migrated through version 8: 66 requests and 66 tests passed. A temporary validation copy supplied the two console tokens using a local harness in the CLI's developer sandbox; that harness is not part of this collection. The original collection's first 13 requests also passed in the default safe sandbox, then correctly stopped at the missing verification-token checkpoint. Starting folder 04 without prior state was rejected before sending a request. All 72 collection, folder, environment, and request YAML files parsed using Bruno's own parser. The desktop workflow was not exercised through the GUI.

Format and runner references: OpenCollection YAML, runtime variables, and prompt variable limitations.