AuthSession is the easiest way to add web browser based authentication (for example, browser-based OAuth flows) to your app, built on top of WebBrowser, Crypto, and Random. If you would like to understand how it does this, read this document from top to bottom. If you just want to use it, jump to the Authentication Guide.
In order to be able to deep link back into your app, you will need to set a scheme in your project app.config.js, or app.json, and then build your standalone app (it can't be updated with an OTA update). If you do not include a scheme, the authentication flow will complete but it will be unable to pass the information back into your application and the user will have to manually exit the authentication modal (resulting in a cancelled event).
The typical flow for browser-based authentication in mobile apps is as follows:
Initiation: the user presses a sign in button
Open web browser: the app opens up a web browser to the authentication provider sign in page. The url that is opened for the sign in page usually includes information to identify the app, and a URL to redirect to on success. Note: the web browser should share cookies with your system web browser so that users do not need to sign in again if they are already authenticated on the system browser -- Expo's WebBrowser API takes care of this.
Authentication provider redirects: upon successful authentication, the authentication provider should redirect back to the application by redirecting to URL provided by the app in the query parameters on the sign in page (read more about how linking works in mobile apps), provided that the URL is in the allowlist of allowed redirect URLs. Allowlisting redirect URLs is important to prevent malicious actors from pretending to be your application. The redirect includes data in the URL (such as user id and token), either in the location hash, query parameters, or both.
App handles redirect: the redirect is handled by the app and data is parsed from the redirect URL.
AuthSession handles most of the app-side responsibilities for you:
It opens the sign in URL for your authentication provider (authUrl, you must provide it) in a web browser that shares cookies with your system browser.
It handles success redirects and extracts all of the data encoded in the URL.
It handles failures and provides information to you about what went wrong.
Additionally, AuthSessionsimplifies setting up authorized redirect URLs by using an Expo service that sits between you and your authentication provider (read Security considerations for caveats). This is particularly valuable with Expo because your app can live at various URLs. In development, you can have a tunnel URL, a lan URL, and a localhost URL. The tunnel URL on your machine for the same app will be different from a co-worker's machine. When you publish your app, that will be another URL that you need to allowlist. If you have multiple environments that you publish to, each of those will also need to be allowlisted. AuthSession gets around this by only having you allowlist one URL with your authentication provider: https://auth.expo.io/@your-username/your-app-slug. When authentication is successful, your authentication provider will redirect to that Expo Auth URL, and then the Expo Auth service will redirect back to your application. If the URL that the auth service is redirecting back to does not match the published URL for the app or the standalone app scheme (eg: exp://expo.dev/@your-username/your-app-slug, or yourscheme://), then it will show a warning page before asking the user to sign in. This means that in development you will see this warning page when you sign in, a small price to pay for the convenience.
How does this work? When you open an authentication session with AuthSession, it first visits https://auth.expo.io/@your-username/your-app-slug/start and passes in the authUrl and returnUrl (the URL to redirect back to your application) in the query parameters. The Expo Auth service saves away the returnUrl (and if it is not a published URL or your registered custom theme, shows a warning page) and then sends the user off to the authUrl. When the authentication provider redirects back to https://auth.expo.io/@your-username/your-app-slug on success, the Expo Auth services redirects back to the returnUrl that was provided on initiating the authentication flow.
If you are authenticating with a popular social provider, when you are ready to ship to production you should be sure that you do not directly request the access token for the user. Instead, most providers give an option to request a one-time code that can be combined with a secret key to request an access token. For an example of this flow, see the Confirming Identity section in the Facebook Login documentation.
Never put any secret keys inside of your app, there is no secure way to do this! Instead, you should store your secret key(s) on a server and expose an endpoint that makes API calls for your client and passes the data back.
Load an authorization request for a code. Returns a loaded request, a response, and a prompt method.
When the prompt method completes then the response will be fulfilled.
🚨
In order to close the popup window on web, you need to invoke WebBrowser.maybeCompleteAuthSession(). See the Identity example for more info.
If an Implicit grant flow was used, you can pass the response.params to TokenResponse.fromQueryParams() to get a TokenResponse instance which you can use to easily refresh the token.
config (AuthRequestConfig) -- A valid AuthRequestConfig that specifies what provider to use.
discovery (DiscoveryDocument) -- A loaded DiscoveryDocument with endpoints used for authenticating. Only authorizationEndpoint is required for requesting an authorization code.
request (AuthRequest | null) -- An instance of AuthRequest that can be used to prompt the user for authorization. This will be null until the auth request has finished loading.
response (AuthSessionResult | null) -- This is null until promptAsync has been invoked. Once fulfilled it will return information about the authorization.
promptAsync (function) -- When invoked, a web browser will open up and prompt the user for authentication. Accepts an AuthRequestPromptOptions object with options about how the prompt will execute. You can use this to enable the Expo proxy service auth.expo.io.
Create a redirect url for the current platform and environment. You need to manually define the redirect that will be used in a bare workflow React Native app, or an Expo standalone app, this is because it cannot be inferred automatically.
Web: Generates a path based on the current window.location. For production web apps, you should hard code the URL as well.
Managed workflow: Uses the scheme property of your app.config.js or app.json.
Proxy: Uses auth.expo.io as the base URL for the path. This only works in Expo Go and standalone environments.
Bare workflow: Will fallback to using the native option for bare workflow React Native apps.
Initiate an authentication session with the given options. Only one AuthSession can be active at any given time in your application; if you attempt to open a second session while one is still in progress, the second session will return a value to indicate that AuthSession is locked.
authUrl (string) -- Required. The URL that points to the sign in page that you would like to open the user to.
returnUrl (string) -- The URL to return to the application. In managed apps, it's optional (defaults to ${Constants.linkingUrl}expo-auth-session, for example, exp://expo.dev/@yourname/your-app-slug+expo-auth-session). However, in the bare app, it's required - AuthSession needs to know where to wait for the response. Hence, this method will throw an exception, if you don't provide returnUrl.
showInRecents (optional) (boolean) -- (Android only) a boolean determining whether browsed website should be shown as separate entry in Android recents/multitasking view. Default: false
Returns a Promise that resolves to a result object of the following form:
If the user cancelled the authentication session by closing the browser, the result is { type: 'cancel' }.
If the authentication is dismissed manually with AuthSession.dismiss(), the result is { type: 'dismiss' }.
If the authentication flow is successful, the result is {type: 'success', params: Object, event: Object }
If the authentication flow is returns an error, the result is {type: 'error', params: Object, errorCode: string, event: Object }
If you call AuthSession.startAsync more than once before the first call has returned, the result is {type: 'locked'}, because only one AuthSession can be in progress at any time.
Cancels an active AuthSession if there is one. No return value, but if there is an active AuthSession then the Promise returned by the AuthSession.startAsync that initiated it resolves to { type: 'dismiss' }.
Get the URL that your authentication provider needs to redirect to. For example: https://auth.expo.io/@your-username/your-app-slug. You can pass an additional path component to be appended to the default redirect URL.
Note This method will throw an exception if you're using the bare workflow on native.
config (AuthRequestConfig) -- A valid AuthRequestConfig that specifies what provider to use.
discovery (IssuerOrDiscovery) -- A loaded DiscoveryDocument or issuer URL. (Only authorizationEndpoint is required for requesting an authorization code).
Used to manage an authorization request according to the OAuth spec: Section 4.1.1.
You can use this class directly for more info around the authorization.
Common use-cases
Parse a URL returned from the authorization server with parseReturnUrlAsync().
Get the built authorization URL with makeAuthUrlAsync().
Get a loaded JSON representation of the auth request with crypto state loaded with getAuthRequestConfigAsync().
// Create a request.const request =newAuthRequest({...});// Prompt for an auth codeconst result =await request.promptAsync(discovery,{ useProxy:true});// Get the URL to invokeconst url =await request.makeAuthUrlAsync(discovery);// Get the URL to invokeconst parsed =await request.parseReturnUrlAsync("<URL From Server>");
Represents an authorization response error: Section 5.2.
Often times providers will fail to return the proper error message for a given error code.
This error method will add the missing description for more context on what went wrong.
Object returned after an auth request has completed.
Name
Type
Description
Default
type
string
How the auth completed 'cancel', 'dismiss', 'locked', 'error', 'success'
.Code
url
string
Auth URL that was opened
error
AuthError | null
Possible error if the auth failed with type error
params
Record<string, string>
Query params from the url as an object
authentication
TokenResponse | null
Returned when the auth finishes with an access_token property
errorCode
string | null
Legacy error code query param, use error instead
If the user cancelled the auth session by closing the browser or popup, the result is { type: 'cancel' }.
If the auth is dismissed manually with AuthSession.dismiss(), the result is { type: 'dismiss' }.
If the auth flow is successful, the result is {type: 'success', params: Object, event: Object }
If the auth flow is returns an error, the result is {type: 'error', params: Object, errorCode: string, event: Object }
If you call promptAsync() more than once before the first call has returned, the result is {type: 'locked'}, because only one AuthSession can be in progress at any time.
Informs the server if the user should be prompted to login or consent again.
This can be used to present a dialog for switching accounts after the user has already been logged in. You should use this in favor of clearing cookies (which is mostly not possible on iOS).
AuthSession has built-in support for some popular providers to make usage as easy as possible. These allow you to skip repetitive things like defining endpoints and abstract common features like language.
Provides an extra loginHint parameter. If the user's email address is known ahead of time, it can be supplied to be the default option.
Enforces minimum scopes to ['openid', 'https://www.googleapis.com/auth/userinfo.profile', 'https://www.googleapis.com/auth/userinfo.email'] for optimal usage with services like Firebase and Auth0.
By default, the authorization code will be automatically exchanged for an access token. This can be overridden with shouldAutoExchangeCode.
Automatically uses the proxy in Expo Go because native auth is not supported due to custom build time configuration. This can be overridden with redirectUriOptions.useProxy.
Defaults to using the bundle ID and package name for the native URI redirect instead of the reverse client ID.
Disables PKCE for implicit and id-token based auth responses.
On web, the popup is presented with the dimensions that are optimized for the Google login UI ({ width: 515, height: 680 }).
request (GoogleAuthRequest | null) -- An instance of GoogleAuthRequest that can be used to prompt the user for authorization. This will be null until the auth request has finished loading.
response (AuthSessionResult | null) -- This is null until promptAsync has been invoked. Once fulfilled it will return information about the authorization.
promptAsync (function) -- When invoked, a web browser will open up and prompt the user for authentication. Accepts an AuthRequestPromptOptions object with options about how the prompt will execute. This should not be used to enable the Expo proxy service auth.expo.io, as the proxy will be automatically enabled based on the platform.
request (FacebookAuthRequest | null) -- An instance of FacebookAuthRequest that can be used to prompt the user for authorization. This will be null until the auth request has finished loading.
response (AuthSessionResult | null) -- This is null until promptAsync has been invoked. Once fulfilled it will return information about the authorization.
promptAsync (function) -- When invoked, a web browser will open up and prompt the user for authentication. Accepts an AuthRequestPromptOptions object with options about how the prompt will execute.
In managed apps, AuthSession uses Expo servers to create a proxy between your application and the auth provider. If you'd like, you can also create your own proxy service.
redirecting traffic from your application to the authentication service
redirecting response from the auth service to your application using a deep link
To better understand how it works, check out this implementation in node.js:
const http =require('http');const url =require('url');constPORT=PORT;constDEEP_LINK=DEEP_LINK_TO_YOUR_APPLICATION;functionredirect(response, url){
response.writeHead(302,{Location: url,});
response.end();}
http
.createServer((request, response)=>{// get parameters from requestconst parameters = url.parse(request.url,true).query;// if parameters contain authServiceUrl, this request comes from the applicationif(parameters.authServiceUrl){// redirect user to the authUrlredirect(response,decodeURIComponent(parameters.authServiceUrl));return;}// redirect response from the auth service to your applicationredirect(response,DEEP_LINK);}).listen(PORT);
Client code which works with this service:
const authServiceUrl =encodeURIComponent(YOUR_AUTH_URL);// we encode this, because it will be send as a query parameterconst authServiceUrlParameter =`authServiceUrl=${authServiceUrl}`;const authUrl =`YOUR_PROXY_SERVICE_URL?${authServiceUrlParameter}`;const result =awaitAuthSession.startAsync({
authUrl,
returnUrl:YOUR_DEEP_LINK,});
There are many reasons why you might want to handle inbound links into your app, such as push notifications or just regular deep linking (you can read more about this in the Linking guide); authentication redirects are only one type of deep link, and AuthSession handles these particular links for you. In your own Linking.addEventListener handlers, you can filter out deep links that are handled by AuthSession by checking if the URL includes the +expo-auth-session string -- if it does, you can ignore it. This works because AuthSession adds +expo-auth-session to the default returnUrl; however, if you provide your own returnUrl, you may want to consider adding a similar identifier to enable you to filter out AuthSession events from other handlers.
If you are using deep linking with React Navigation v5, filtering through Linking.addEventListener will not be sufficient, because deep linking is handled differently. Instead, to filter these events you can add a custom getStateFromPath function to your linking configuration, and then filter by URL in the same way as described above.