Authenticated testing lets Tahr test functionality that requires login. Use dedicated test users and a controlled non-production target, never employee or production administrator accounts. Review the Security Notices before configuring identities.
#When to enable authenticated testing
Enable authenticated testing when important functionality is behind login, including dashboards, account settings, admin areas, tenant data, or API actions that require a session. Leave it off for public-only targets, recon, or source-code-only work. Configure the setting and related readiness inputs in Application Setup.
#Login URL and Authentication Check URL
The Login URL is the full public HTTP(S) URL where sign-in begins. It can be an application login page, a custom tenant identity provider, or another public authentication provider, and must be publicly reachable.
The Authentication Check URL is one or more full URLs on the configured application or API origin that prove the resulting session belongs to a user. It should return user-specific data, for example:
/me/profile/account/api/me/api/user
Choose the endpoint that best represents your application. A generic page, health check, public homepage, static asset, or route that always returns 200 is not sufficient: if anonymous and authenticated requests receive the same response, Tahr cannot confirm that login succeeded.
Use Extra context for authentication in the application to explain SSO redirects, tenant or workspace selection, fixed test CAPTCHA behavior, post-login confirmation, protected areas to avoid, and unusual session or timeout behavior. Keep this guidance concise and free of passwords, API keys, recovery codes, and other secrets.
Test the Authentication Check URL with the same account and environment that the assessment will use. It should identify the current user or return another response that changes when the session is absent. Third-party or custom identity-provider redirects can be public intermediate steps; the final check must be on the configured application or API origin.
For recorded Google or Microsoft flows, use the configured provider account, complete the provider's approved HTTPS authorization flow, and continue back to the application, API, or a verified organization domain.
#Test users
Create dedicated test users before setup and document each user's:
- Role, such as viewer, member, manager, or admin.
- Tenant, workspace, or organization, if the application is multi-tenant.
- Permissions needed to exercise important workflows.
- Object ownership or other data boundaries relevant to authorization.
Use the least privilege needed for each test. For authorization testing, provide intentionally different roles, tenants, and object owners so Tahr can compare what each user may view or change. Do not use real customer data or personal employee accounts. A Tahr-managed email address may be used when the selected email flow needs Tahr to receive a code or magic link.
Record which account owns representative objects when object-level authorization is in scope. Include a permitted user and a deliberately different user where the workflow must distinguish ownership. Run authenticated assessments only against a dedicated non-production target. Keep test data disposable and avoid actions that send real notifications or delete shared data.
#Second-factor authentication
Customer-visible test flows may use email or magic-link codes, SMS codes, authenticator-app (TOTP) codes, or a fixed code in a controlled test environment. Enable second-factor handling for the users that need it and provide the per-user method requested by the form. Mixed setups are valid: some test users may require a second factor while others do not.
For email or magic-link testing, use a dedicated managed inbox and follow the login flow shown by the application. For SMS, use an organization-controlled test number. For TOTP, use a test account's authenticator setup. Fixed codes should be limited to non-production test accounts and rotated according to your team's policy. See SSO accounts and SMS numbers when those capabilities require organization configuration.
#Managed email and SMS
For a dedicated test identity, generate and copy the managed email address before using it in the application. Save the application and test identity first, then use Check latest email for email or magic-link messages and Check latest SMS for text messages. Messages can take time to arrive, and SMS availability is limited. Use these only with dedicated test identities.
#SSO accounts
If your organization supports managed SSO test accounts, choose a configured Google or Microsoft account rather than putting full account details in the application. During login, choose Sign in with Google or Sign in with Microsoft, select the assigned test account, and complete the provider prompts shown by Tahr.
Do not use the same SSO test account for concurrent active assessments. Choose another account or wait for the first assessment to finish; shared login state can make results unreliable. Keep provider credentials in the managed SSO flow, not in free-text application fields.
#Sign-in automation
Use Sign-in automation when credentials alone cannot represent a multi-step flow, such as SSO redirects, tenant selection, or post-login prompts. Add the Login URL first, then choose Record sign-in, allow browser pop-ups if asked, and complete only the approved login journey. If the local recorder is blocked by a WAF or does not open, use Open live view. Choose Finish recording when the journey is complete.
Wait for the recording to save, then check its saved status and recorded timestamp. Review it before use. Choose Record again to replace it, Upload recording to provide an approved recording file, Change file to replace an uploaded file, or remove it when it is no longer needed. Do not capture unrelated secrets, personal accounts, recovery codes, or activity outside the approved identity-provider redirects. See Sign-in automation for the application workflow.