[Dev Tools] Auth server for sso accounts are very, very slow

[TicTacWeb3]

Team or Project

Syntra

ZK chain

ZKSync ERA

Environment

Testnet

Select the Dev Tool you are using

ZKsync CLI

Provide the version of the tool (if applicable)

"zksync-sso": "^0.2.0"

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

i'm successfully using the repository, but I'm encountering a significant issue with the authentication server's performance. User login attempts are extremely slow, often resulting in server timeouts and failed logins.
While logins do succeed occasionally, the inconsistency and high failure rate are problematic. I've also tested with a local authentication setup, and the performance issues persist.
Is there a known solution or any troubleshooting steps I can take to address this latency and improve the reliability of the login process?

Repo Link (Optional)

https://github.com/matter-labs/zksync-sso

Additional Details

No response

[bxpana]

Will check with the SSO team to see if this is to be expected

[TicTacWeb3]

thank you very much 💪🏻

[cpb8010]

I can help!

Can you provide which requests fail? Is it when trying to open the pop-up, load the javascript & HTML, or are they on-chain requests?
In terms of performance, the authentication "server" only uses era sepolia testnet, which appears to be performing normally: https://uptime.com/statuspage/era/3408985 and the auth-server front-end is hosted with Fastly, which also appears nominal: https://www.fastlystatus.com/

I've also tested with a local authentication setup, and the performance issues persist.

When you say "local" do you mean running the auth-server page locally pointed to era sepolia?
Do you mean making requests from a local dapp to the default (auth-test.zksync.dev) auth-server?
Or do you mean with the SSO contracts deployed to a local node with a local dapp?

[TicTacWeb3]

I can confirm i have this problem also on the demo app : https://nft.zksync.dev/

[TicTacWeb3]

i'm noticing that if I introduce a delay between attempts, the initial attempt seems to have a higher probability of success. I'm wondering if there might be a programmed delay or cooldown period between tries

[cpb8010]

Yes, it does sound like this is a gap between the browser and the passkey device not fully connecting.
We've seen certain types of passkeys have different rates of success (and some just refuse to work!), and while we don't currently collect any telemetry error reports from this, it's something we'd love to narrow down so we can adjust the passkey settings.

Again, it looks like you've tried a number of different configurations with different levels of success. I can outline what we've tested with so far and see if that matches up with what you've saw.

Here's what I have that works on the default settings:

• Fedora + Chromium + Yubikey
• Fedora + Chromium + QR/Bluetooth
• Fedora + Firefox + Yubikey
• Windows 11 + Chrome + Windows Hello
• Windows 11 + Edge + Windows Hello
• Windows 11 + Chrome + Yubikey
• Windows 11 + Chrome + QR/Bluetooth
• Android 15 + Chrome + Native Passkey
• Android 15 + Firefox + Native Passkey

And then you said the following works:

• iOS + Safari + Native Passkey

It sounds like what doesn't work is:

• Arch + ?Chromium? + QR/Bluetooth
• Windows + ?Chromium? + QR/Bluetooth

I'd check a reference passkey QR implementation (https://www.passkeys.io/), then maybe Bluetooth drivers on the computer?

If the reference implementation works, but the demo-app doesn't, the only other way to debug this when running the auth-server locally (pnpm nx dev auth-server) is to adjust the generate registration options in passkey.ts.

I made a quick branch if you want to pull this to try: https://github.com/matter-labs/zksync-sso/tree/test-passkey-auth

Otherwise I'd love to hear more about what you have that doesn't work, since it's hard to get total coverage of all passkey combinations so we can provide better guidance and change settings depending on the detected platform.

[TicTacWeb3]

I've tried various combinations in passkey.ts, but it doesn't seem to be an issue with the zkSync-sso repo code.
I'm starting to suspect it might be a compatibility issue at the web protocol layer.