In that scenario, the IDP cannot access any of its cookies and cannot identify the user anymore. It is now a “Third-Party” request, and this is where the Intelligent Tracking Prevention kicks in. The silent refresh happens in an iframe the address of the IDP isn't a “First-Party” request anymore as the hybrid app is creating the iframe in its DOM. In the ITP's point of view, this is all fine the browser will store the cookie as usual. Anything with a different domain is a “Third-Party” instead. To clarify, a “First-Party” is everything under the browser's main address hosting the current site. During the login accessing the IDP is the “First-Party” request. The client app can do a silent refresh via an iframe when the current short-living access token expires while this cookie is available. The IDP itself stores a long-living cookie that identifies the user. When a hybrid app uses the Implicit Flow, it redirects to an IDP where the login happens and gets an access token back appended to the return URL. What does this mean for hybrid apps? Let's look at one specific scenario used in many apps: The OAuth Implicit Flow Based on Cookies with Silent Refresh If you want to read more about ITP, you can head to :Įverything was fine when “just” browsing, but in iOS 14 (or iPadOS 14), the ITP (in version 2.3) was also activated (“on” by default) in the WKWebView. The principal task of the ITP is to keep the user more private when browsing the internet and prevent tracking by advertising companies like Facebook, Google, and more. Since then, it was included in the operating system's Safari browser (macOS, iPadOS, iOS) and updated over time. The Intelligent Tracking Prevention From Version 1.0 to 2.3Īpple introduced the first version of Intelligent Tracking Prevention (ITP) in June 2017. Starting with iOS 14, the Intelligent Tracking Prevention raises some problems in Cordova or Capacitor apps, especially when the OAuth Implicit Flow based on Cookies with Silent Refresh is used for login and authentication.
0 kommentar(er)
