Can I get cookies from Safari in a SFSafariViewController?

3
votes

tl;dr; see the question below

In my app, I have a login that uses SFSafariViewController and ASWebAuthenticationSession that follows the OAuth 2.0 flow (Using the AppAuth library).

The login works and the cookies are shared with Safari as expected. Thanks to the cookie sharing, users are automatically logged-in if they use the Safari app.

However, back in the app, if I launch a SFSafariViewController again, the cookies are missing. This surprises me, because I thought the cookie Store is the same for SFSafariViewController and Safari, and it clearly worked in the direction from SFSafariVC to the Safari app during login. Is it intended not to work the other way round - from Safari to SFSafariViewController, or is it a bug?

I have not found clear statements in the documentation. Of course I have not set ephemeral session to true, but according to the documentation it would do the opposite of what I want to achieve:

When not using an ephemeral session, all cookies except session cookies are available to the browser.

I've also found somehow related radars like http://www.openradar.me/33323462 and http://www.openradar.me/radar?id=5036182937272320 or this stackoverflow post: Why is SFSafariWebViewController not sharing cookies with Safari properly? but they do not answer my question.

According to this comment it could work if the cookies have an expiry date (set to a future date). I verified the cookies - they all have a future expiry date.

My question: Am I doing something wrong, or is this expected behaviour, that SFSafariViewController does not get cookies from an earlier SFSafariViewController instance in the same app or from Safari?

1
ioscookiessafariopenid-connectsfsafariviewcontroller

1 Answers

1
votes

REQUIREMENTS

So it seems you want a solution to invoke secured web content from a mobile app, and to avoid an extra login. It is a common requirement and I will be adding some stuff to my blog on this topic over the next month or so.

STATE OF THE INDUSTRY

The problem with the above is that third party cookies, such as those issued by Identity Providers, are often dropped by default these days due to browser security initiatives such as Intelligent Tracking Prevention changes - which is ON by default in Safari:

enter image description here

COOKIE PROPERTIES

Worth checking that your cookies are issued with SameSite=None, which will give you the best options for a third party cookie based solution.

MOBILE FIRST DESIGNS

In an OAuth world, in order to meet the requirements, it is likely to be necessary to send a token from the mobile UI to the web UI, which of course has prerequisites that need to be designed for:

  • Web UI must use tokens
  • Web UI must use different strategies for token handling depending on the host

OPTION 1

One option is to use a mobile web view to show the web content - see my code below:

OPTION 2

Another option is to send something representing the token in a query string parameter from the mobile app to the Web UI, in which case you need to ensure that:

  • No usable tokens are recorded in web server logs
  • The token has a one time use only

A typical implementation would look like this:

  • Mobile UI calls an /api/token/encrypt endpoint
  • API stores a token hash in a database and returns an encrypted value with a short time to live
  • Token is sent from the Mobile App to the Web UI
  • Web UI calls an /api/token/decrypt endpoint to get the real token
  • The API's decrypt implementation deletes the database entry