Reuse an authenticated Internet Identity (II) session in Playwright tests

Developers
1

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.

:magnifying_glass_tilted_left: 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.

⸻

:locked: 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

2

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
3

image
image1165×1280 70.3 KB

image
image1165×1280 62.6 KB

image
image1165×1280 95.7 KB

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
4

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

5

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

6

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
7

I’m really sorry to bother you again with this issue but I still don’t know how to use the dummy_auth, I have added the url query param but I still don’t see no changes to the authentication method (now the url looks like : http://uzt4z-lp777-77774-qaabq-cai.localhost:4943/#authorize?FEATURE_FLAG_DISCOVERABLE_PASSKEY_FLOW=true), could you show me pictures of how it should work and where to use the dummy_auth

8

You need to deploy the canister with the dummy_auth config to enable it in 2.0:

dfx deploy internet_identity --argument "(opt record { dummy_auth = opt opt record { prompt_for_index = true }})

prompt_for_index = true enables multiple dummy passkeys by prompting for an index of choice, each index represents a different dummy passkey.

prompt_for_index = false means you won’t be prompted for an index. This does mean you won’t be able to create multiple identities, since every dummy auth passkey would be the same index (0) without the prompt.

9

These guys found something else using bash script