I am currently building a social network / marketplace on ICP (using Rust for the backend canisters) and I am now moving on to building the native iOS client (Swift).
I am struggling to correctly connect my native iOS app with Internet Identity. Since II relies heavily on WebAuthn and domain origins, I am finding it difficult to implement a smooth and secure authentication flow outside of a standard web browser.
Could the community or DFINITY engineers point me in the right direction? Specifically, I would like to know:
What is the current recommended architecture/flow for iOS + II? (e.g., generating a session key locally → using ASWebAuthenticationSession → getting a delegation → deep linking back to the app).
Are there any actively maintained Swift SDKs (Agent.swift) or boilerplates that handle the II delegation flow out of the box?
Alternatives: Would it be better/easier to use NFID or other auth providers for a native mobile experience instead of raw Internet Identity?
Any code snippets, GitHub examples, or documentation links would be greatly appreciated. Thanks in advance!
These JSON-RPC requests for Internet Identity are accepted at https://id.ai/authorize.
As mentioned in the first link, it’s highly recommended to use associated domains for native applications to ensure Internet Identity recognizes your applications with an identifier you control contrary to a custom scheme that any app could implement.
I’m aware that the above isn’t great documentation or a step by step guide, but hopefully it contains what you need to get things working
I wonder if it would be worth it for someone to build a test app and write the docs.
There’s a lot of room for improvement in the user facing flow of authenticating and inside an iOS app it seems illogical to think that it will be like a 2fa where users have to leave app, go to browser, authenticate with passkey, return to app and maintain the session.
Going to a browser (view) is the common authentication flow for any authentication protocol except for specific tightly integrated platform cases (Google sign-in on Android and Apple sign-in on iOS).
This doesn’t mean the user has to literally go back and forth to their browser, most platforms (specifically iOS and Android) support a special view that renders the web interaction within the app itself while not giving the app access to the page. The OP already mentioned ASWebAuthenticationSession as an example in that regard.
Most authentication is build on the OIDC protocol that goes over the same web browser back and forth navigation concept that II now also supports. We can’t directly support the OIDC protocol itself given the decentralized nature of the Internet Computer that’s incompatible with bearer tokens kept secret by SSL transport, contrary to message signatures that don’t rely on such secrecy at all.
It’s been on our list for a while to look into creating documentation and/or libraries for native apps, but we haven’t been able to prioritize it yet unfortunately.
What’s cool is I have a subscription to chat gpt (20 dollar a month plan) and I will ask it to begin this process. I will post my work in this thread.
Thank you so much for the detailed explanation and the links to the ICRC-167 and ICRC-34 standards! It perfectly clarifies the flow. It’s great to see that II now supports link-based communication. I will look into implementing Universal Links (Associated Domains) on iOS for a secure callback. Really appreciate your help!
Makes total sense! The explanation regarding Bearer tokens vs. Message signatures perfectly highlights the architectural difference of ICP. I will proceed with ASWebAuthenticationSession and Universal Links. Thank you for the clarity, it’s exactly what I needed to move forward!"
