This package is deprecated in favor of AuthSession. Check out the authentication guides to learn how to migrate your existing authentication today.
expo-app-auth allows you to authenticate and authorize your users through the native OAuth library AppAuth by OpenID.
Many services that let you authenticate with them or login with them, like GitHub, Google, GitLab, etc., use the OAuth 2.0 protocol. It's the industry standard.
If you are trying to implement sign in with Google or Facebook, there are special modules in the Expo SDK for those (though this module will work).
You will want to decide on a URI scheme for your app, this will correspond to the prefix before :// in a URI. Ex: If your scheme is mychat then a link to your app would be mychat://.
The scheme only applies to standalone apps and you need to re-build the standalone app for the change to take effect. In the Expo Go app you can deep link using exp://ADDRESS:PORT where ADDRESS is often 127.0.0.1 and PORT is often 19000 - the URL is printed when you run expo start.
If you want to test with your custom scheme you will need to run expo build:ios -t simulator or expo build:android and install the resulting binaries in your emulators. You can register for a scheme in your app.json by adding a string under the scheme key:
{"expo":{"scheme":"myapp"}}
To create a scheme that is appropriate for the environment, be sure to use Linking from expo:
There are a couple different methods for authenticating your app in React Native and Expo, this should help you know if expo-app-auth is right for your needs.
The AuthSession API is built on top of expo-web-browser and cuts out a lot of the tricky steps involved with web authentication. Both AppAuth and AuthSession use SFAuthenticationSession and ChromeCustomTabs to authenticate natively, but AppAuth has built in support for OpenID. AuthSession uses an extra Expo service that makes development easier (especially across teams) but this can have some extra security considerations.
The expo-app-auth module is based on react-native-app-auth by the incredible React.js consulting firm Formidable. The documentation and questions there may prove helpful. expo-app-auth provides a few extra features to make native app auth work inside a sandboxed Expo Go environment.
Redirect scheme used to assemble the redirectUrl prop. In standalone apps, this is either the android.package (for Android) or ios.bundleIdentifier (for iOS) value from your app.json. However, for apps running in Expo Go, AppAuth.OAuthRedirect is host.exp.exponent.
Learn more about OAuth Parameters on this exciting page: openid-connect-core.
To save time I've copied over some of the relevant information, which you can find below.
Name
Type
nonce
OAuthNonceParameter | undefined
display
OAuthParametersDisplay | undefined
prompt
OAuthPromptParameter | undefined
max_age
OAuthMaxAgeParameter | undefined
ui_locales
OAuthUILocalesParameter | undefined
id_token_hint
OAuthIDTokenHintParameter | undefined
login_hint
OAuthLoginHintParameter | undefined
acr_values
OAuthACRValuesParameter | undefined
Other parameters MAY be sent. See Sections 3.2.2, 3.3.2, 5.2, 5.5, 6, and 7.2.1 for additional Authorization Request parameters and parameter values defined by this specification.
type OAuthDisplayParameter='page'|'popup'|'touch'|'wap';
ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User.
Value
Description
page
The Authorization Server SHOULD display the authentication and consent UI consistent with a full User Agent page view. If the display parameter is not specified, this is the default display mode.
popup
The Authorization Server SHOULD display the authentication and consent UI consistent with a popup User Agent window. The popup User Agent window should be of an appropriate size for a login-focused dialog and should not obscure the entire window that it is popping up over.
touch
The Authorization Server SHOULD display the authentication and consent UI consistent with a device that leverages a touch interface.
wap
The Authorization Server SHOULD display the authentication and consent UI consistent with a "feature phone" type display.
The Authorization Server MAY also attempt to detect the capabilities of the User Agent and present an appropriate display.
type OAuthPromptParameter='none'|'login'|'consent'|'select_account';
Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent.
Value
Description
none
The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required, or another code defined in Section 3.1.2.6. This can be used as a method to check for existing authentication and/or consent.
login
The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.
consent
The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required.
select_account
The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically account_selection_required.
The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request. If this parameter contains none with any other value, an error is returned.
String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. For implementation notes, see Section 15.5.2.
End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.
ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.
Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.) When max_age is used, the ID Token returned MUST include an auth_time Claim Value.
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.
Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2. The acr Claim is requested as a Voluntary Claim by this parameter.