You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From our perspective, this works just like any other social auth in
many cases. It's set up to conform to our protocol of giving a
redirect to a URL with the `zulip://` scheme containing the API key.
These cases (where the normal protocol is used) are
- Android
- iOS before version 13
- On servers not operated by the same people as the publishers of
the mobile app (so for the official Zulip app, by Kandra Labs) [1]
In the remaining cases (Kandra-hosted realms on iOS 13+), we'll do
the native flow. This means we initiate the auth by using an iOS API
that natively handles querying for, e.g., the user's fingerprint,
face, or password, and gives us an `id_token`, which we send to the
server. Currently, we do this by opening the browser and awaiting
the same `zulip://` redirect, same as in the normal protocol.
As a followup, we may want to tweak this so it's not necessary to
ever open the browser in the native flow. We could just use `fetch`
and expect the API key in the response.
[1]: We don't want to send an `id_token` from the native flow to one
of these realms; see discussion around
https://chat.zulip.org/#narrow/stream/3-backend/topic/apple.20auth/near/918714.
0 commit comments