WeWork Mobile SSO — Amazon Federate Integration Notes

Summary

We've integrated SSO sign-in in the WeWork mobile app and it works end-to-end with a standard Okta-style IdP. For the Amazon Federate client it currently fails on mobile, because Federate routes to Midway, and Midway tries to open an external app on the same device (aea://). A mobile in-browser sign-in cannot launch that app, so the flow dead-ends.

We believe the fix is for Federate to use a device-code / polling flow on mobile (the same activate.amazon-corp.com code screen Amazon already has), instead of the same-device app hand-off. That pattern works in a mobile browser exactly like our Okta flow does. This doc explains all three flows and what we need from your side.

How sign-in works on mobile (the key constraint)

The WeWork app opens the IdP in the device's system browser (Chrome Custom Tabs on Android, ASWebAuthenticationSession on iOS) and waits for a redirect to our registered callback URL, which the app intercepts.

The system browser can follow web redirects and poll, but it cannot reliably launch a separate native app mid-flow (e.g. via an aea:// link). So any IdP step that depends on opening another app on the same device breaks the mobile flow. Authentication that happens out-of-band (on another device, or via a background push) and then redirects the browser page to the callback works perfectly.

Flow 1 — Working reference (Okta-style)

This is live and working in our app today.

[Diagram]

Why it works: the approval happens out-of-band, the browser page just polls, and on success the same page redirects to our callback. The browser never has to open another app.

Flow 2 — Amazon Federate today (fails on mobile)

[Diagram]

Why it fails: Midway requires the browser to launch the AEA app on the same device via aea://. In a mobile system browser that hand-off does not happen (app not present / the auth session will not launch a third-party app), so the flow never reaches our callback. This is a hard limitation of mobile browsers, not something we can work around in the app.

Flow 3 — Expected flow (device-code / polling) — what we need

This matches the activate.amazon-corp.com screen Amazon already shows (enter a code on your computer, the phone screen waits). It restores the same out-of-band

[Diagram]

The mobile phone never needs the AEA app. AEA/Midway runs where it already works (the managed laptop), and the phone's browser simply polls and then redirects to our callback, just like Okta.

What we need from the Amazon Federate team

  1. Enable the device-code / polling flow for our mobile client (wework-india-staging) instead of the Midway aea:// same-device app redirect. Mobile should land on the activate.amazon-corp.com style code screen and poll.
  2. On successful authentication, redirect the polling page to our registered redirect URI with the standard OIDC code and state. Our redirect URI is: https://wwistaging.in/auth/sso/callback.
  3. Confirm the callback contract is unchanged (code + state on the redirect; we exchange them server-side as we do today).
  4. Confirm this mode can be set per client (so it applies to our mobile client without affecting desktop), and whether it needs a specific authorize parameter or client configuration on your side.
  5. Share timing/TTL for the device code and the polling window, so we match our session timeout.

If a device-code flow is not available, the alternative is any auth method that does not require launching the AEA app on the phone (credentials/MFA in the page, or out-of-band push) and ends by redirecting the browser to our callback.

Why we can't fix this only on the app side

We open the IdP in the OS system browser specifically because it is the secure, standard way to do SSO on mobile and lets the redirect hand back to our app. That same browser will not launch the AEA app for us, and embedding a custom in-app browser to force-launch aea:// is both unreliable and a security regression. The clean fix is the device-code flow above, which keeps all Amazon authentication on the managed device where it is designed to run.

Alternative: if we support the AEA app hand-off

If the device-code flow is not possible and you want us to support the same-device AEA app hand-off instead, that is a larger, non-standard effort. Before we could commit to it, we would need the following from your team:

  1. Outbound scheme. The exact custom scheme and URL format Federate/Midway redirects to in order to open the AEA app (e.g. aea://...), and whether it is stable across environments.
  2. Return path. How control comes back from the AEA app after it finishes Midway. Does the AEA app redirect to our registered redirect URI (https://wwistaging.in/auth/sso/callback) directly, hand back to the browser that launched it, or open a scheme our app must register? We need the exact return URL/scheme and the code + state contract on that return. Without this, even if we open the AEA app, we have no defined way for the result to return to the WeWork app, so the loop cannot close.
  3. Caller requirements. Whether the calling app or device must be enrolled/managed for the AEA app to accept the request and return a result, or whether any app can initiate the aea:// hand-off.
  4. Existing precedent. Is there any other third-party or partner app that already integrates this AEA hand-off on mobile today? If so, we'd like to reference that integration or be connected with that team, since this pattern isn't publicly documented.
  5. Platform support. Confirmation it works from both Android (Chrome Custom Tabs) and iOS (ASWebAuthenticationSession), including whether iOS even allows the auth session to launch the AEA app.
  6. Prerequisites. AEA app installed, managed/enrolled device, minimum OS, and any other device posture requirements.

Why we don't embed an in-app WebView

A tempting shortcut is to host the IdP in an in-app WebView (a browser embedded inside our app) so we could detect and launch aea:// ourselves. We deliberately do not do this, because it is a security regression and is rejected by SSO best practice:

  1. The host app can see everything in a WebView. The embedding app can inject JavaScript, read the page contents, and observe input. Users would effectively be typing their corporate SSO credentials into a surface a third-party app controls. This is exactly what OAuth 2.0 for Native Apps (RFC 8252) prohibits; it mandates the system browser instead.
  2. No trust indicators. A WebView has no address bar or TLS/lock indicator, so users cannot verify they're on the genuine Amazon sign-in page. This is a classic phishing vector.
  3. No OS protections or shared session. WebView sign-in bypasses the system browser's protections and cookies, and breaks passkeys, device trust, and the conditional-access / managed-device checks that AEA and Midway rely on.
  4. Major IdPs block it. Google, Microsoft, and others actively refuse embedded WebView sign-in for these reasons, and AEA's gating very likely would too.

The system browser (Custom Tabs / ASWebAuthenticationSession) is the secure, sanctioned approach, which is why our integration uses it and why the device-code flow is the right fix.