Playwright Auth Flow Automation
Publicada el 2026-07-26
Descripción de la oferta
# Playwright Expert for Complex Authentication, MFA and Session Persistence I need an experienced Playwright engineer to build a reliable browser-automation application for complex authenticated workflows. The application will be used only with portals and accounts that our company owns or is explicitly authorized to access. The target workflows may include: * Username and password authentication * SMS or email one-time codes * Authenticator-app TOTP * Trusted-device or remembered-device confirmation * Saved browser sessions * Session expiration * Operator-assisted authentication * Unexpected login errors or additional security challenges The priority is reliability, security, and clear failure handling. ## Required Authentication Flow On every run, the application must follow a session-first process: 1. Check whether an active authenticated browser session is available. 2. If available, verify that it is still authenticated and belongs to the correct account. 3. If no active browser is available, attempt to load an encrypted saved Playwright storage state. 4. Verify the restored session using the authenticated URL, visible account elements, and the absence of login or error screens. 5. If the saved session is no longer valid, start the approved reauthentication workflow. 6. If the portal presents CAPTCHA, an access-denied page, account lock, or an unexpected security challenge, stop and request manual intervention. 7. Save a new session only after authentication has been fully verified. The application must reuse an authenticated session only while it remains valid. It must respect the portal’s natural session expiration and security controls. ## MFA and OTP Support The application must support authorized MFA workflows, including: * SMS one-time codes * Email one-time codes * Authenticator-app TOTP * Manual code entry when automatic retrieval is unavailable OTP retrieval must be implemented through configurable hooks or provider integrations. Possible integrations include: * Twilio inbound SMS webhook * Secure email inbox or inbound-email webhook * Encrypted TOTP-secret integration * Manual operator entry Requirements: * Match each code to the correct account and active login challenge. * Reject old or expired codes. * Prevent one code from being consumed by the wrong job. * Never write OTP codes to application logs. * Do not request repeated codes automatically. * Stop after an invalid code or unexpected challenge. Authenticator-app secrets, when used, must be encrypted at rest and must never be included in source code or configuration files. ## Trusted-Device Handling When the portal legitimately presents a “Trust This Device,” “Remember This Device,” or equivalent option, the application should: 1. Detect the option. 2. Select it when enabled in the account configuration. 3. Verify that the option was accepted. 4. Save the resulting authenticated browser state securely. 5. Reuse the saved state on future runs while it remains valid. The application must not manipulate security cookies, browser fingerprints, CAPTCHA systems, or portal protections. ## Manual Authentication Mode When automatic authentication cannot continue, an authorized operator must be able to open the same Playwright browser in visible mode. The operator should be able to: * View the current browser page * Complete an unexpected authentication step * Enter an OTP manually * Confirm a trusted-device prompt * Resume the workflow * Cancel the run * Record an operator note Headed and headless execution must use the same underlying workflow and selectors. ## Error Detection The application must detect and clearly report: * Invalid credentials * Expired session * Invalid OTP * OTP timeout * Account lock * CAPTCHA * HTTP 403 or access-denied response * Unexpected authentication challenge * Selector or page-layout change * Browser crash * Network timeout * Incorrect account or profile * Saved session belonging to the wrong account The application must stop rather than attempt to bypass CAPTCHA, access restrictions, or security blocks. ## Security Requirements Credentials and authentication secrets must not be stored in a normal configuration file. Use: * Environment variables * Docker secrets * A managed secrets service * Replit Secrets * HashiCorp Vault * AWS Secrets Manager * Another approved secure vault Saved session artifacts must be: * Separate for each account * Encrypted at rest * Protected by restricted permissions * Written atomically * Excluded from Git * Excluded from logs * Invalidated when no longer trusted * Protected against simultaneous writes Passwords, OTP codes, cookies, local-storage values, and TOTP secrets must never appear in screenshots or standard logs. ## Technical Requirements Preferred implementation: * Playwright * TypeScript and Node.js Python with Playwright may also be considered when the developer can explain the advantage. The project must include: * Clear account configuration * Separate browser context for every account * Secure session persistence * Structured error handling * Configurable OTP retrieval hook * Manual authentication mode * Audit logs with sensitive information redacted * Reliable selector strategy * No arbitrary fixed delays where a Playwright condition can be used * Screenshot or trace capture for failures, with sensitive fields redacted * Docker support * One-command local startup ## Acceptance Criteria 1. Playwright TypeScript project runnable with one documented command. 2. Credentials are loaded from environment secrets or a vault, not committed configuration files. 3. Each account has isolated session storage and browser context. 4. The application tries a valid saved session before beginning a new login. 5. Expired sessions safely enter the reauthentication workflow. 6. SMS and email OTP retrieval are supported through configurable hooks. 7. Authenticator TOTP is handled securely or through manual operator entry. 8. Old OTP messages cannot be used by a new login attempt. 9. Trusted-device state is saved only after successful verification. 10. CAPTCHA, account lock, access denial, and unexpected challenges stop the workflow. 11. Headed and headless modes use the same business logic. 12. The application avoids brittle fixed waits and uses Playwright conditions. 13. Sensitive information is removed from logs, traces, and screenshots. 14. Automated tests are included using a mock or staging authentication portal. 15. A README explains setup, session reset, credential rotation, troubleshooting, and extension of the authentication flow. ## Demonstration The selected developer must demonstrate the workflow using one of the following: * A mock authentication portal * A staging portal * Our authorized portals after hiring * A sanitized previous project the developer is legally permitted to show Do not access or demonstrate automation against a third-party account without authorization. ## Required Experience Strong experience is required in: * Playwright * TypeScript or Python * Complex authenticated browser workflows * MFA and OTP integration * Browser-session persistence * Secure cookie and local-storage handling * Twilio or email webhooks * Docker * API integration * Error detection and recovery * Secure credentials management Experience only with simple web scraping is not sufficient. ## Screening Questions Please answer these questions in your proposal: 1. Describe a complex Playwright login workflow you previously built. 2. How would you securely store Playwright session state? 3. How would you prevent an old OTP from being submitted during a new login? 4. How would you match an SMS or email code to the correct account? 5. How would you verify that a restored session belongs to the correct account? 6. What should happen when the portal displays CAPTCHA, HTTP 403, or an account-lock message? 7. How would you allow manual authentication without duplicating the automated workflow? 8. How would you prevent two browser processes from using the same account simultaneously? 9. How would you redact passwords and OTP fields from traces and screenshots? 10. Which stack do you recommend and why? Please include relevant examples that you are authorized to share.
Skills
Fuente original: freelancer