To protect (at least a bit) from tracking one could disable third party cookies in the browser.
How to prevent from being tracked by service-workers left by ads (running in iframes)?
If I understand this right then it's possible that service-workers modify any request sent to such an ad site (even if the request originates from an iframe). So the service worker could add some 'identifier' to the request header which would offer the same tracking possibilities as the blocked cookies.
Related
Our app has an OIDC provider and for our users, we use the standard OAuth redirect flow since user authorization and authentication are performed on the same device. However, now we have mobile users within our app we want to extend authentication to the app.
I've been looking a OIDC CIBA flow and not sure if it is right for us and I wanted to make sure.
During the verification/authentication stage of OIDC we traditionally display a login screen. However, I am thinking for mobile use cases we can just show a "polling" screen to indicate a back channel request has been made.
Since we have the device token (through a pairing phase at some point before) we can send a push notification to the phone and ask the user to approve the request. Using mTLS for encryption I can ensure a secure connection to the device. The polling screen will poll an API by a UUID for the result (the mobile device will make a success API call after approval). Once it has the result it will redirect the user back to the OIDC redirect flow.
This means we don't need to introduce CIBA and just have a new verify screen that will perform the async work then redirect once done.
There may be a couple of use cases you are mentioning here. For each I would aim to follow the most standard solution, with simplest code in apps and best options for extensibility.
WEB APP LOGINS ON A DESKTOP
Sometimes a login in a desktop browser involves a mobile device, eg if I log in to gmail in a desktop browser I am prompted to confirm that it's me on my mobile device. This triggers a call to Google's APIs, and meanwhile the login screen polls the same APIs, to detect completion.
MOBILE APP LOGINS
Extending the flow to work for mobile should work in the same way. Gmail uses the AppAuth pattern from RFC8252 to sign me in, then presents the same prompt to confirm it's me. In this case there is no need to switch devices. Also of course the mobile login has no dependencies on the user having access to a desktop, so that authentication works in mobile scenarios.
CODE FLOW
Both of the above use the code flow, with multi-factor authentication. Passwords are the primary factor (something the user knows) and a Polling Authenticator is the second factor (requires the user to have ownership of the device). Once you are using the code flow, your apps support many ways to authenticate and the authentication workflow can be changed without needing to change at the authorization server without changing any application code.
MOBILE FACTORS
There are a few different types here:
Time Based One Time Password (TOTP): apps such as Google Authenticator ask the user to enter a 6 digit number which is calculated the same both on the device and in the authorization server.
Polling: The login screen polls the Authorization Server, which in turn polls an external system to see if the user login has completed, as in the gmail case above.
App2App: In some cases the primary authentication factor can be an external app. This type of solution is also implemented via the code flow, as explained in this app2app article.
CIBA
This is a different use case, typically used when User A needs access to some of User B's resources temporarily. The classic case is when a call centre operator needs to act on behalf of a user. The call centre app then triggers a flow that results in the remote user being prompted to sign in. See this tutorial and video for an example. It does open up some interesting possibilities, such as delivering tokens via push notifications.
SUMMARY
Implementing a mobile login by getting the user to provide something they know on a desktop, then delivering a push notification, feels over complicated and non-standard. It might work against the mobile architecture also, eg preventing logins if the user is on a train.
I would favour the AppAuth pattern and implementing mobile logins in the standard way, by getting the user to provide something they know on the device. It is likely to provide the most secure behaviour and also the best all round architecture. If you have special reasons for wanting to do things differently, you should update your question to explain why.
Does the new app tracking transparency popup give access to third party cookies in the webview?
We're trying to show Scorm files in an iframe in the webview. This requires access to third party cookies which is blocked by default. In the iOS versions <14.5, we needed to go to app settings and enable Cross-app tracking toggle to enable third party cookies. There was no way to show a popup for this in the app directly.
This is one of the many reasons that SCORM providers often choose to display the launched SCORM content as a new window instead of an iframe. The new window also allows for better tracking of session-end timings. However I find that that new window launching will come with its own set of problems.
There have been numerous changes in Safari (and other browsers) regarding cookies and iframe.
The basics of what is changing is there is now a 'SameSite' cookie policy, where Only cookies set as SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections.
In Safari, the third-party frame will have to request access to the storage API before the cookie will be accessible.
Cookie Status is an excellent resource to track how third party cookies work in the different browsers and what you should change to make it work.
I have native iOS app and one of the flows of the app should be done with WebView. From native part of the app, user can navigate to WebView part. And, somehow, web page should identify user. I have authorization token stored in the app and of course I can pass that token in the headers of the WKWebView. And other stuff will be handle in the web (routing and etc). But is it a good and secure way of doing this? How can I easily integrate WebView in the app caring about token?
There are a few options here:
Using headers seems problematic according to this thread but hopefully you can get it to work. It feels like this will have reliability problems if the token ever expires in the web view, so you'll need to manage that.
Simple option: open a system browser - either Safari or a Safari View Controller. The user may have to sign in again though, which your stakeholders may not like.
More complex option: use the Javascript API to pass the token from the mobile UI to the web UI. This will give you full control, and the web app can call back the mobile app to refresh its token. It can be the best usability option if used sparingly. It requires tricky foundational work in both the web and mobile UIs though.
SECURITY
Passing the token from the Mobile UI to the Web UI is natural if both are part of the same logical application and access the same level of data. In this case option 1 or 3 would work.
If the apps have very different security levels (eg the web app is now getting a much higher privilege token than it usually gets), then I would not pass the token and would use option 2 instead.
FURTHER DETAILS
I wrote a quite detailed blog post on considerations a while back, and there is also a code sample you can run:
Blog Post
Mobile Bridge Code in Web UI
Javascript Bridge Code in Mobile UI
I'm not sure there is a "proper" way, but before I just bodge together my own incompatible implementation, perhaps there's something in all the standards that can fit my need?
Here's the situation: Apple has declared that apps on their phones MUST include all standard functionality inside themselves. No more iframes with web content! If you need to show stuff from web, open the system browser (Safari)! Unfortunately we need to display stuff from web, so here we go...
Now, the app requires authentication which the user has done previously. We store whatever tokens we need. When the time comes to open the browser, we don't want to force the user to re-authenticate. We need to somehow pass the access credentials to the browser, and preferably do this securely. Furthermore, the webpage in the browser will need a token obtained from our OpenID Connect server.
Unfortunately, the only point of communication between the app and the browser is the URL, so everything that we give will be there, in plain sight. I know that OAuth was pretty worried about this, so much so that they made it impossible to intercept authentication with just the stuff visible on the screen and instead using things like single-use intermediary codes, backchannels and PKCE.
Unfortunately I cannot see any way to use the default flows "out of the box" to achieve what I need. I can think of modifications to those flows that would do it, but I'm not a security expert so I'd rather go with something standard which is vetted by experts.
SCENARIO
It's a good question since many companies want to show existing web content in a secured manner within a mobile app, and to avoid an extra login.
WEB + MOBILE INTEGRATED SOLUTION VIA DISCONNECTED BROWSER?
Ideally what you want to do is pass the mobile app's JWT to the external web content in an HTTP header. iOS APIs such as openURL may not support this however.
You may have to pass a JWT in a query string, in which case I would try to follow a signed request model, though it is not trivial. I have used SalesForce signed requests though not implemented a full solution myself.
Mobile app calls an API method at POST /api/encrypt-token
API returns an encrypted payload that includes the JWT
Mobile app opens a web page at https://mywebapp?token=0a78904cwdu
Web UI calls POST /api/decrypt-token to get the JWT
Web UI stores the token in memory and uses it to call the API
You will want to prevent raw tokens being written to web server logs.
I believe the recommendation for this type pf solution is to use a one time key, as described in the above link. And of course the web session will have some limitations such as silent token renewal not working.
WEB + MOBILE INTEGRATED SOLUTION VIA WKWEBVIEW
In the past I've managed secured web content in a mobile app by making the Web UI get access tokens from the mobile app. This enables an integrated UX and you can use a 'standard as possible' OAuth solution.
When the Web UI runs within a mobile app's web views it no longer does its own OAuth handling and instead calls the mobile app to get tokens and trigger logins
This means there is a single login across web and mobile views, and the Web View gets all the benefits of mobile user experience, such as secure storage of tokens
The Web UI is no longer impacted by things like the web view aggressively dropping cookies
VALID USE OF WEB VIEWS?
Web views are probably not a good long term solution in most cases. I know that Apple are likely to reject apps in 2020 if they use any of these behaviours:
Use of UIWebView - the Cordova default - you need to update to WKWebView
Delivering an app that is solely a repackaged web site with no mobile views
Displaying web content of a dubious nature (ads etc)
I suspect that use of WKWebView used responsibly and justifiably would be accepted. I could be wrong though, so please don't take my word for it.
ONLINE SAMPLES
I will be documenting some stuff about mobile / web integration on my OAuth blog, including code samples.
My ultimate goal is to make the web site GRPR compliant that contains Youtube embed videos. Originally I used youtube.com, but then found youtube-nocookie.com, but it creates the NID cookie. Does it violate the GDPR principle? Ghostery tracker doesn't detect trackers in this case, but requests come in Chrome Network.
Any first or third-party cookies require consent except for those "strictly necessary" to provide the service, so for example first-party session cookies to store login status do not need permission, load balancer ones probably don't either, especially if they are short-lived.
Ghostery isn't a great authority because they accept payment from ad companies to ignore certain cookies. Try Ublock Origin and Better tracker blockers for a more ethical take.
youtube-nocookie.com is probably just a proxy that strips cookies - but there's nothing preventing you from building that functionality yourself - nginx is easy to configure as a proxy and can strip cookies.
This is all somewhat vague because you don't show details of the cookies you mention, what domains they are coming from, what kind of cookies they are, what's in them, how long they live etc, and all of those things have some bearing. Fundamentally, cookies don't themselves violate GDPR, but tracking cookies without consent certainly do.
https://policies.google.com/technologies/types?hl=en-US
That cookie is used to store user preferences, not for usage or advertising tracking.