Skip to content

Add native (React Native) OAuth sign-in - #123

Draft
onelxj wants to merge 1 commit into
mainfrom
onelxj.native_oauth_wip
Draft

Add native (React Native) OAuth sign-in#123
onelxj wants to merge 1 commit into
mainfrom
onelxj.native_oauth_wip

Conversation

@onelxj

@onelxj onelxj commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

React Native can't use Reboot's browser sign-in flow: there is no window.location to redirect and no cookie jar shared with the backend. Teach the same OAuth server and React client to run the standard authorization-code flow with PKCE that native apps use, so a mobile app writes the same useSignIn() / useSignOut() / useUser() as a web SPA does.

Backend:

  • Application(native_redirect_uris=[...]) lets an application claim the redirect URIs of its own first-party native apps. A client that registers only such URIs signs its user in directly, as the browser client already did; every other dynamically registered client still gets the consent screen, which is what stands between a user and an attacker who registers a client with their own redirect_uri. Expo development URIs are trusted by shape under rbt dev run only — deliberately not localhost, which MCP clients also register.
  • /__/oauth/whoami additionally accepts an Authorization: Bearer access token, so a native app can resolve its default_ids without hardcoding which state types are auto-constructed.

React client:

  • RebootClientProvider takes an optional nativeAuth, and useSignIn() / useSignOut() dispatch to it. Omitted — as on the web — everything behaves exactly as before.
  • A new @reboot-dev/reboot-react/native subpath carries the whole OAuth protocol (discovery, RFC 7591 registration, PKCE, token exchange, refresh), plus expoAuth() for Expo apps. It adds no dependency to @reboot-dev/reboot-react: the pieces React Native has no standard answer for are passed in and typed structurally, which also lets an app's own type-checker confirm its installed Expo version matches. SHA-256 is carried here rather than taken from a platform module, for the same reason.

The bank-pydantic mobile front end now signs in, and is scoped to the signed-in user like the web front end.

React Native can't use Reboot's browser sign-in flow: there is no
`window.location` to redirect and no cookie jar shared with the
backend. Teach the same OAuth server and React client to run the
standard authorization-code flow with PKCE that native apps use, so a
mobile app writes the same `useSignIn()` / `useSignOut()` /
`useUser()` as a web SPA does.

Backend:

- `Application(native_redirect_uris=[...])` lets an application claim
  the redirect URIs of its own first-party native apps. A client that
  registers only such URIs signs its user in directly, as the browser
  client already did; every other dynamically registered client still
  gets the consent screen, which is what stands between a user and an
  attacker who registers a client with their own `redirect_uri`. Expo
  development URIs are trusted by shape under `rbt dev run` only —
  deliberately not localhost, which MCP clients also register.
- `/__/oauth/whoami` additionally accepts an `Authorization: Bearer`
  access token, so a native app can resolve its `default_ids` without
  hardcoding which state types are auto-constructed.

React client:

- `RebootClientProvider` takes an optional `nativeAuth`, and
  `useSignIn()` / `useSignOut()` dispatch to it. Omitted — as on the
  web — everything behaves exactly as before.
- A new `@reboot-dev/reboot-react/native` subpath carries the whole
  OAuth protocol (discovery, RFC 7591 registration, PKCE, token
  exchange, refresh), plus `expoAuth()` for Expo apps. It adds no
  dependency to `@reboot-dev/reboot-react`: the pieces React Native
  has no standard answer for are passed in and typed structurally,
  which also lets an app's own type-checker confirm its installed
  Expo version matches. SHA-256 is carried here rather than taken
  from a platform module, for the same reason.

The `bank-pydantic` mobile front end now signs in, and is scoped to
the signed-in user like the web front end.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@aviator-app

aviator-app Bot commented Aug 5, 2026

Copy link
Copy Markdown

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This pull request is currently open (not queued).

How to merge

To merge this PR, comment /aviator merge or add the mergequeue-ready label.


See the real-time status of this PR on the Aviator webapp.
Use the Aviator Chrome Extension to see the status of your PR within GitHub.

@onelxj
onelxj marked this pull request as draft August 5, 2026 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant