Sign-in

People sign in with their own Superroute account. Each sign-in is for one app at one service provider.

Superroute sign-in page

Always available. The app opens the sign-in page in the system browser with PKCE, and exchanges the code it returns for tokens. The page lists what the app asks for; sensitive capabilities are listed separately and can be declined. Accounts with two-step verification sign in here.

const { url, verifier } = await sr.auth.authorizationUrl({ redirectUri: 'com.acme.parcels:/oauth' });
// open `url` in the system browser, then with the code it returned:
await sr.auth.exchangeCode({ code, redirectUri: 'com.acme.parcels:/oauth', verifier });

// On a phone, in an in-app browser session:
await sr.auth.signInWithBrowser({ redirectUri, open });

let request = try await sr.authorizationRequest(redirectURI: "com.acme.parcels:/oauth")
// present request.url in an ASWebAuthenticationSession, then:
try await sr.completeSignIn(request, returnedURL: callbackURL)

Google or Apple

The app runs the platform's own Google or Apple sign-in and passes the ID token. Available when the app registered its Google or Apple identifiers and the service provider allows that sign-in method.

await sr.auth.signInWithIdToken(googleIdToken);        // JavaScript
await sr.signInWithIdToken(googleIdToken);             // Dart
try await sr.signIn(idToken: appleIdToken)             // Swift
sr.signInWithIdToken(googleIdToken)                    // Kotlin
await sr.SignInWithIdTokenAsync(googleIdToken);        // C#

Email and password

In the app's own screens, only for an app Superroute approved for it (capability app.password_sign_in) and when the service provider allows email sign-in.

Tokens and sessions

Tokens are kept in the token store you pass (Keychain, Android Keystore, Windows data protection or your own). They are refreshed before they expire, one refresh at a time, and a refused refresh ends the session. People see their sign-ins to the app and can end any of them.

Endpoints