Follow-up: Got Internet Identity working across multiple domains

Developers
1

I finally got consistent II principals across all my game domains. This was giving me trouble for a while, so here’s what ended up working.

What fixed it

Using Alternative Origins + derivationOrigin.

I created a small asset canister that serves the .well-known/ii-alternative-origins file. Any domain that should share the same identity goes into that JSON.

Here’s mine:

{
  "alternativeOrigins": [
    "https://mygame0.com",
    "https://mygame1.com",
    "https://mygame2.com"
  ]
}

Then I point my login call to derive the identity from the asset canister instead of the game domain:

authClient.login({
  identityProvider: "https://identity.ic0.app",
  derivationOrigin: "https://my-asset-canister.icp0.io"
});

That gives me the same principal on every site, which was the goal.

Why the asset canister?

II expects the .well-known endpoint to be certified.
Motoko’s http_request can’t certify responses, so it fails with 503s.
Asset canisters handle certification by default, so it just works.

My setup

  • Asset canister (serves the origins file): ktox6-6qaaa-aaaan-q2hfa-cai
  • Backend canister: fdvph-sqaaa-aaaap-qqc4a-cai
  • Adding new domains = update the JSON + redeploy the asset canister

If anyone else is doing multi-game or multi-tenant identity and needs help, feel free to ask.

1 Like
2

It’s not the cleanest approach, but it gets the job done. Once II gets more official support for multi-domain setups, I’ll probably revisit it.

3

This is super helpful. Thanks!

4

Here is another canister you can use instead of an asset canister for the same purpose: derivation-origins/src/server.mo at main · research-ag/derivation-origins · GitHub

It is more lightweight than the full asset canister, written in Motoko (asset canister is Rust), and has a simpler interface. You can set and change domains with a simple set command and query them with a get command. It has exactly 10 slots for domains because II supports up to 10 alternative origins.

2 Likes
5

Ah, thank you

I didn’t actually realise the 10-origin limitation on II.

I thought I’d solved the problem but this definitely needs a bit more consideration. Appreciate the pointer.

6

Right, depending on what you want to do the 10-origins limits can be a problem.

In my case I wanted to deploy immutable frontends so that each new frontend version is deployed in a new canister and user can opt-in to use the version but the old versions always remain available. Of course, logging in with II should result in the same principal across all versions. This can be achieved with a dedicated derivation origin canister and works for the first 10 versions, say v1 through v10. When v11 comes out then v1 has to be dropped from the derivation origin. At that point users can no longer use v1 because they wouldn’t get the same principal anymore.

For frontend versions the limit may be acceptable, but I can see that if you want the same identity across many game frontends then it is not. I don’t see a good solution because II doesn’t support application groups.