Legacy --oauth flags moved to Traffic Policy: preserving allowlist semantics during migration

Migration context

I am moving an ngrok tunnel definition from the legacy per-tunnel flags (the --oauth option with an email/domain allowlist) to the newer Traffic Policy configuration, where the same control is expressed as an ordered rule with an OAuth action. The goal is to gate a local app behind provider login (e.g., Google) for integration testing, without embedding OAuth client credentials in the app under test.

Uncertainty

Traffic Policy rules are evaluated in order and the first matching terminating action wins. The legacy flags had implicit, fixed semantics, so it is unclear whether a hand-written policy reproduces them exactly — particularly the interaction between the OAuth action, the allowlist enforcement, and any additional rules (such as IP restrictions) that were previously separate flags. Behavior parity also appears to depend on the agent version, and I have not confirmed which agent version introduced full coverage of the legacy OAuth options.

Questions

• When converting --oauth plus an email allowlist into a Traffic Policy rule, what ordering guarantees that unauthenticated requests never reach the upstream app?
• Is there a documented mapping or compatibility boundary between each legacy flag and its Traffic Policy equivalent per agent version?
• Should the application still duplicate the authorization check after edge OAuth, or is edge enforcement considered sufficient?