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 realms that are not hosted by Kandra [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 a
server that's not associated with the official mobile app; see
discussion around
https://chat.zulip.org/#narrow/stream/3-backend/topic/apple.20auth/near/918714.
0 commit comments