[auth-session] Create built-in providers for Google and Facebook

[EvanBacon]

Why

• Too much config is needed to perform Google and Facebook auth. This leads to complicated docs and repetitive code. We can simplify this by creating built-in providers for the most popular solutions.
• Create a suitable replacement for expo-google-app-auth and expo-google-sign-in.
• Improve support for Firebase. Resolve [docs] Add info on using AuthSession with Firebase #8185 [auth-session] [WIP] Missing "usePKCE" and typo in Firebase guide for Google #9177
• Help cut down on mistakes like this Auth session sometimes ends with "Something went wrong trying to finish signing in." #8957 (comment)

How

• Introduce the response.authentication property which gets initialized when an auth request finishes with response.params.access_token. This is the same TokenResponse that would be returned from exchanging an auth code for an access token.

• Created built-in providers:

import * as Google from 'expo-auth-session/providers/Google';
import * as Facebook from 'expo-auth-session/providers/Facebook';

// ...

Google.useAuthRequest({ 
  expoClientId: '',
  iosClientId: '',
  androidClientId: '',
  webClientId: ''
})

Facebook.useAuthRequest({ 
  clientId: '',
})

• These improve auth by abstracting the discovery, scopes, useProxy, usePKCE, and redirectUri logic away (with ability to overwrite the abstraction). The abstraction helps the docs to focus more on provider setup rather than Expo configuration.

Google

• Docs: https://github.com/expo/expo/blob/@evanbacon/auth-session/providers/google-init/docs/pages/guides/authentication.md

• No need for useProxy to be defined because the request will automatically use it in the Expo client and disable it elsewhere.

• Discovery is built-in.

• windowDimensions are built-in.

• In native projects the auth code will be automatically exchanged for an access token.

• Automatically generate async nonce parameter and add it to the loading hook's pipeline.

import * as Google from 'expo-auth-session/providers/Google';

const [,response, promptAsync] = Google.useAuthRequest({ 
  expoClientId: '',
  iosClientId: '',
  androidClientId: '',
  webClientId: ''
})

React.useEffect(() => {
  if (response?.type === 'success') {
    console.log(response.authentication);
  }
}, [response])

Google Firebase

Firebase requires the id_token to be properly created. On native this can be achieved using the standard authentication, but on web you can only get the id_token when the response_type=id_token is used. Because of this I've reluctantly created an extension of Google.useAuthRequest which switches the response type on web or when using the proxy service.

const [,response, promptAsync] = Google.useIdTokenAuthRequest({ 
  expoClientId: '',
  iosClientId: '',
  androidClientId: '',
  webClientId: ''
})

React.useEffect(() => {
  if (response?.type === 'success') {
    console.log(response.params.id_token);
  }
}, [response])

Facebook

• Facebook defaults to using Implicit auth instead of Auth code response type. This is because you cannot exchange a code without a server or the client secret.
• Default scopes are optimized for Firebase and other providers.
• Any form of Facebook auth can be used with Firebase afaict.
• Automatically generate async nonce parameter and add it to the loading hook's pipeline.

import * as Facebook from 'expo-auth-session/providers/Facebook';

const [,response, promptAsync] = Facebook.useAuthRequest({ 
  clientId: '',
})

React.useEffect(() => {
  if (response?.type === 'success') {
    console.log(response.authentication);
  }
}, [response])

General

• almost of the opinions can be overridden, either by dropping down to AuthSession.useAuthRequest or with other properties.
  • Proxy defaults can be overridden with the second parameter, i.e. Facebook.useAuthRequest({}, { useProxy: true })
  • Auto exchange on Google can be disabled with config.shouldAutoExchangeCode

Test Plan

Updated NCL tests to reflect the changes.

• Test all response types (implicit, auth code, id-token).
• Test bare-expo on iOS, and Android.
• Test NCL in the client on iOS, and Android.
  • iOS
  • Android redirects seem broken in the client: Google auth redirect opens new instance of app #9522
• Test web NCL.
• Test Standalone (via custom clients?).
• Ensure Firebase flows work as expected.

[github-actions]

Native Component List for this branch is ready

[EvanBacon]

Probably need something like expo fetch:android:hashes instead.

[brentvatne]

you may already know this and i'm just misreading the comment but expo fetch:android:hashes does this already, the value you're looking for is "Google Certificate Fingerprint"

[EvanBacon]

I mean if you run it in any Expo project that isn't built for prod you get:

Configuring credentials for bacon in project native-component-list
There is no valid Keystore defined for this app

Effectively meaning that in dev you need to set it to one value then change it in prod or create another Google key which is worse.

[SleeplessByte]

The current way everything is set-up, íf you want to use Google App Signing AND you want expo builds to have a different key store, you must have two google keys. Google's "recent" restrictions on those keys are weird, as almost all google systems allow for multiple values (all other android key restrictions).

And I figured out today, before seeing this PR, documented in #9391, you will need 3 separate keys anyway -- it's not thát weird to have a different key per bundle/release channel.

[EvanBacon]

I've just opened an issue to make the CLI return a keystore on demand without requiring a build expo/expo-cli#2456 this would effectively cut out one more key upfront for Android auth.

[SleeplessByte]

That's a good idea. I don't think having to have 3-4 keys is that problematic, but the fact that the "openssl" command is cryptic as best makes this a very good win, I think.

[EvanBacon]

I think it's problematic currently because currently you:

• get fake hash -> register Google key with fake hash -> expo build it -> get actual key -> register new Google key -> update codebase -> expo publish again.

After this you could

• get future hash -> register Google key with real hash -> expo build it.

Much easier to document, test, and develop.

[SleeplessByte]

Yeah, I think making this process for Google Play Store simpler is much much better. I did exactly what you say in the "before" list, and it's confusing if you don't know what's going on.

But that's not what I meant with it not being problematic. I meant that having a key for expo-non-google builds and google-signed builds does make sense -- so has nothing to do with the process of acquiring that key, but with the fact that we still should be able to support at least 2 keys for Android projects, 1 key for iOS and 1 key for Web.

Why?

If there can only be one Android key, non-google signed builds will no longer work, making the internal testing process far worse, and also make it much harder to have a google signed build for the play store and a expo signed build for all the other stores (amazon, samsung etc.).

Right now the real process is:

1. expo build (you don't need anything other than the basic project and app.json` -- you don't need to use a fake key at the moment, you can just have this command generate it on the expo servers).
2. expo fetch:android:hashes to get the hash
3. Add a new google key with this hash, and update your project accordingly.
4. expo build to get a working standalone build which won't work with app signing, but will work on non play stores / direct install

Optional for standalones:

4. Upload the build to the play store to turn on App Signing and retrieve the hashes
5. Add a new google key with this hash, and update your project accordingly
6. expo build once more to get a working standalone build, to be used for the store

---

With your new proposed flow, if I understand correctly, it's:

1. expo build (you don't need anything other than the basic project and app.json -- you don't need to use a fake key at the moment, you can just have this command generate it on the expo servers).
2. expo fetch:android:hashes to get the hash
3. Add a new google key with this hash, and update your project accordingly.
4. expo build to get a working standalone build which won't work with app signing, but will work on non play stores / direct install

Optional for standalones:

4. Upload the build to the play store to turn on App Signing and retrieve the hashes
5. Add a new google key with this hash, and update your project accordingly
6. expo build once more to get a working standalone build, to be used for the store

Or am I missing something here?

[doronnahum]

Hi @EvanBacon ,
the provider folder is not published to the npm package

You can validate that by click on the Create-google-app button in the docs
https://docs.expo.io/guides/authentication/#google

[ottob]

the provider folder is not published to the npm package

I can confirm this on sdk 38. I just did a expo install expo-auth-session and got [email protected]. This functionality will probably be released in sdk 39?

Is it documented somewhere when to use expo-auth-session compared to the expo-facebook package for authentication?

[doronnahum]

I tried to follow this guide:
https://docs.expo.io/guides/authentication/#facebook

import * as Facebook from 'expo-auth-session/providers/facebook';
''''

[ottob]

I tried to follow this guide

I did too :)

But if you look here https://github.com/expo/expo/blob/master/packages/expo-auth-session/CHANGELOG.md the new provider features are in version v1.5.0 and that has not been released yet for the 38 sdk. Im not sure if it can be cherry-picked to the sdk-38 branch or if it depends on changes in the 39 sdk. @EvanBacon probably knows.