We’re using a local mock version of Internet Identity (not the production one), which assigns anchor numbers like 1000, 1001, etc. The goal is to avoid repeating the login process in every Playwright test by saving and reusing the authentication state.
Problem Summary
• Playwright’s storageState only captures cookies, localStorage, and sessionStorage.
• Internet Identity (even the local mock version) uses WebAuthn, which involves:
• Cryptographic credentials tied to the device/browser
• Unserializable credentials that are not stored in storageState.json
• When Playwright restores the state from storageState.json, it doesn’t restore WebAuthn, so the II session appears logged out even though other data is restored.
⸻
Why this happens
1. WebAuthn credentials are device-bound and can’t be exported or replayed.
2. storageState cannot include WebAuthn credentials.
3. Internet Identity (mock or real) relies on WebAuthn to complete login, so auth breaks after restoring Playwright state
With the II 2.0 frontend rewrite we recently ran into the same issue while moving to Playwright, in the end we moved to using a canister deployment flag to swap out the passkey implementation with a dummy implementation that prompts for a key pair seed instead of webauthn.
See the e2e tests here: internet-identity/src/frontend/tests/e2e-playwright at main · dfinity/internet-identity · GitHub
And canister deployment arguments needed for the above tests:
dfx canister install internet_identity --wasm internet_identity_test.wasm.gz --argument "(opt record { captcha_config = opt record { max_unsolved_captchas= 50:nat64; captcha_trigger = variant {Static = variant { CaptchaDisabled }}}; related_origins = opt vec { \"https://id.ai\" }; new_flow_origins = opt vec { \"https://id.ai\" }; dummy_auth = opt opt record { prompt_for_index = true }})"
Particularly the dummy_auth config is what makes the frontend use a constant key pair instead of webauthn. If you intend to run tests with multiple identities you’ll need to also set prompt_for_index to true.
Previously in II 1.0 we ran e2e tests in WebDriverIO with the VirtualAuthenticator API that mocks the WebAuthn in the browser. This does unfortunately mean that if you intend to test with II 1.0, you’ll be stuck with the VirtualAuthenticator API, which is less trivial to work with in e2e tests.
1 Like
Hey, I am working with Ali on this issue and we are still having a hard time figuring out how to implement it in a test.
I’ve added screenshots so you can see what we have when using this particular II canister with dummy_auth. In your message I understood that we could login with a key pair seed instead of webauthn.
But when I try to create a new user, I don’t see the keypair option.
Please tell me if I am just using it the wrong way or if there is a problem somewhere
1 Like
The dummyAuth deployment argument is only implemented in II 2.0 (load page with url + ?FEATURE_FLAG_DISCOVERABLE_PASSKEY_FLOW=true to switch to 2.0).
If you want to use dummyAuth in II 1.0, you’ll need to use the development build flavor. Keep in mind that dummy auth doesn’t allow for multiple identities in II 1.0 while it does in II 2.0
So the II canister we deploy is version 1.0 and should actually be 2.0 for the dummy_auth to work ? Am I forced to enable it in the url or can I already deploy a 2.0 version canister ?
Thanks for your important help
II 2.0 and 1.0 are the same canister, the url query param I mentioned above toggles between the versions.
In 1.0 dummy auth is only a build flavor while in 2.0 it can also be enabled through a deployment argument.
2 Likes
