I’m trying to create an auth flow with WebBrowser.openAuthSessionAsync (as per docs), but I’m having trouble accessing the cookies from the page after a user successfully logs in. It seems that the WebBrowser API doesn’t have a clean way of accessing, yet its .openAuthSessionAsync() method is the recommended approach (outside of using AuthSession - which is not an option for non-FB or Google accounts).
So I suppose my question is: how does one use WebBrowser.openAuthSessionAsync() to successfully auth a user?
I’d recommend reading up on OAuth2 workflows. It works essentially the same as an OAuth2/ OpenID Connect login on the web, except, instead of redirecting back to a website, you need to redirect back to an app using the app’s URI scheme (e.g., those “yourapp://something” URL’s you might see some places).
In general, it’s something like:
Open the login page in a web browser
User logs in
Login page redirects back to the app with information in the URL (not cookies) that is needed to login. This could be a code that is exchanged for an access token by using another endpoint (the “authorization code” workflow) or the access token itself (the “implicit” workflow), which is then used on future requests to the server.
So, if you’re using WebBrowser.openAuthSessionAsync(), the result when that completes will include the full redirect URL called by the login page (I believe this is only true on iOS 11 - to get the redirect URL on Android, you need to use the Linking API to listen for the app-specific URL). This will include your code or access token. No cookie reading required. In fact, I think it’s even impossible to read the cookies from these browser windows even in the base iOS or Android code.
Where cookies come into play with the “AuthSession” is that the browser windows it opens on each OS (SFAuthenticationSession on iOS and Chrome Custom Tabs on Android) have access to the OS browser’s cookie jar, so, if you had logged into the authentication provider on in the browser, then you would still be logged in when your React Native app goes to that site. If you use openBrowserAsync(), then it uses an embedded browser window that does not have access to the OS browser cookie jar.
@llamaluvr I may need to draw upon your expertise once more The above approach is working as expected (open a browser, get an auth token from the url, and store that in the app state with the Linking API), however, I’m running into one major exception:
If a user is logged in (the auth token stored in the AsyncStorage) and then logs out (clearing the storage and bringing them to the login window once more), the Safari window (opened with WebBrowser.openAuthSessionAsync) hits the same login url as before, however, seems to cache the cookies of the logged in session when they open up the login window.
This is very strange - and what’s more, when the WebBrowser tries to load the hosted sign in page, fails to load, simply showing a blank screen saying ‘Website Name’ at the top (where the auth page title would normally be). If I completely force quit the app and reopen, I’m able to hit the log in page as normal again.
Is this anything you’ve seen before? It seems related to saving my cookies from the previous session, which I thought was the opposite of one of the main selling points for openAuthSessionAsync()…
I can’t explain the page load failing (sounds like it might be specific to your login page), but the other behavior you’re seeing is perfectly normal. The sales pitch for auth session / SFAuthenticationSession/ Chrome Custom Tabs, is that they use the same cookie jar as the operating system browser. Therefore, if a user logs into Google in Safari, and then later uses an app with Google login, they will not have to log into Google again- they just have to accept that the app wants to use their Google login for the app’s login. This puts the “single” in “Single Sign-On”. When you log out of the app, you’re only clearing the session token in the app, not the token the browser cookies (you can’t clear that), so that’s why you don’t need to enter a password on the next login attempt. In such a case, it’s often a good idea for the login page to confirm that this is the correct user before redirecting to the app, in order to allow the user to sign in as somebody else (Google login does this in my experience).
I see, thanks so much. Yep, the shared cookie jar makes sense for SSO. As for the weird Safari window, my best guess is that I may be seeing something like this: https://github.com/expo/expo/issues/1233, except in iOS.
On a related note- is there any way to see logs of all that Expo is doing in iOS, other than Simulator’s debug logs (e.g. inspecting the network traffic)?
The above approach is working as expected (open a browser, get an auth token from the url, and store that in the app state with the Linking API), however, I’m running into one major exception: