ASWebAuthenticationSession cookie

We are using ASWebAuthenticationSession with apps on IoS to achieve SSO between apps. The IdP for authentication (OIDC) is an on-premise and trusted enterprise IdP based on one of the leading products in the market. Our problem is that the user is prompted for every login (and logouts) with a consent dialogue box: “AppName” wants to use “internal domain-name” to Sign In This allows the app and website to share information about you. Cancel Continue” I have read in various places that Apple has a concept of “Trusted domains” where you can put an “Apple certified” static web-page on the IdP. This page needs to contain specific metadata that iOS can verify. Once a user logs in successfully a few times, and if the IdP is verified as trusted, subsequent logins would not prompt the consent screen. Question: I struggle to find Apple documentation on how to go about a process that ends with this “Apple certified web-page” on our IdP”. Anyone who has experience with this process, or who can point me in some d

Hello everyone, In my application, i have implemented authentication using ASWebauthenticationSession. However, when redirecting the user to a WKWebView, no cookies are shared, causing the session to be lost and requiring the user to log in again. Is there a way to share cookies between the two? If not, what would be the best approach to set up authentication that ensures SSO when switching to a WebView ? Thank you very much for your help !

PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.3.2 Run-time configuration: iOS 15-18 This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie. We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies. – The following is a snippet from an explanation to the WebKit Slack: We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are i

We are currently using Single Sign-On (SSO) for user authentication within our app, which is presented through a web view. This web view includes a cookie banner that allows users to either accept, reject all, or manage cookies. In some reviews, Apple suggests implementing App Tracking Transparency (ATT) if cookies are used. In other reviews, Apple may refer to guideline 5.1.2, which states: “Revise the app so that users are not required to enable tracking in order to access the app's content and functionality.” I have a few questions regarding the interaction between ATT and the cookie banner: 1 Is App Tracking Transparency required for the cookie banner?
If yes, iOS developers have no direct control over the cookies used on the webpage when the user selects Ask App Not to Track or Allow. Despite this selection, the cookie banner still appears, prompting the user to accept or reject cookies. 2 How should App Tracking Transparency be impl

We’re encountering an issue when trying to add non-standard headers to outgoing requests using Declarative Net Request (DNR) rules in our Safari Web Extension. Tested on macOS 15.4 with Safari 18.4. Specifically, when attempting to add a custom header such as X-Custom-Header using a DNR rule, the header does not appear in the request. We are able to add standard headers like Authorization and Cookie to the request successfully using the same method. This behavior suggests that Safari may be filtering or blocking non-standard headers when set via DNR rules, unlike other browsers. In Chrome and Firefox, the same rule adds the X-Custom-Header header without any issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

We are planning to use our internal IdP (PingFederate) for authentication of end users in their iOS apps using ASWebAuthenticationSession. Initial tests are successful, but the user is prompted for every login (and logouts) with a consent dialogue box: “AppName” wants to use “internal domain-name” to Sign In This allows the app and website to share information about you. Cancel Continue” Let’s say that our top-level domain is “company.no”, where our IdP is placed at “idp.company.com”. I have seen examples where the Associated domains entitlement points to the idp as a webserver for serving the JSON output AASA file. In this case that would be: authsrv: idp.company.com Anyone with experience implementing this structure with the IdP as webserver for serving the JSON output? Our problem is that trying to use the IdP as webserver for this purpose is that it is very complicated to modify the IdP’s webserver configuration. Also, this modification needs to be re-done every time we need to upgrade the IdP. M

We're hitting an issue where Safari on Mac renders a page fine for a period of time but then, for unknown reasons, fails to load some resources stored on a different (unauthenticated) subdomain if 'crossorigin=anonymous' is specified. These are the same resources (css, js) that had been loaded fine earlier in the session. The hosting of the resources is consistent. Safari doesn't produce any errors, it just hangs forever appearing to request the resources. We believe this is a CORS related issue for a couple of reasons. This only happens to resources that are loaded with 'crossorigin=anonymous' Once Safari is in a broken state, the toggling on Disable Cross-Origin Restrictions will let the page load, and toggling it off again will return it to the broken state. The only other way to fix the browser session is to quit and restart Safari. I've logged a Safari bug/feedback but haven't heard anything back. Does anyone have any idea how to solve this without removing the crossorigin parameter from these resources?

I'm developing an iOS app that utilizes Universal Links and ASWebAuthenticationSession to deep-link from a website to the app itself. This implementation adheres to the recommendations outlined in RFC 8252, ensuring that the app opening the ASWebAuthenticationSession is the same app that is launched via the Universal Link. Problem: 　While most users can successfully launch the app via Universal Links,a few percent of users experience instances where the app fails to launch, and the user is redirected to the browser. What I've Tried: 　ASWebAuthenticationSession Configuration: I've double-checked the configuration of callbackURLScheme and presentationContextProvider. 　Universal Links: Verified the apple-app-site-association file and associated domains entitlement. 　Network Conditions: Tested on various network environments (Wi-Fi, cellular) and devices. Questions: 　What are the potential causes for this behavior? 　Has anyone else encountered a similar issue and found a solution? 　Are

Hi everyone, I am trying to use ASWebAuthenticationSession to authorize user using OAuth2. Service Webcredentials is set. /.well-known/apple-app-site-association file is set. When using API for iOS > 17.4 using new init with callback: .https(...) everything works as expected, however i cannot make .init(url: ,callbackURLScheme: ....) to work. How can i intercept callback using iOS <17.4? Do I really need to use universal links? callbackURL = https://mydomain.com/auth/callback

Is there any particular reason why ASWebAuthenticationSession doesn't have support for async/await? (example below) do { let callbackURL = try await webAuthSession.start() } catch { // handle error } I'm curious if this style of integration doesn't exist for architectural reasons? Or is the legacy completion handler style preserved in order to prevent existing integrations from breaking?

I am creating a Safari Web Extension. There are two calls let say, call1 and call2 which gets executed in sequence by browser, call1 gives a 302 type response and redirects to call2. When creating DNR rule for adding Cookie in the request header of call1, the same cookie gets added to the request header of call2 as well(Same is the case for other headers/custom headers as-well). Because of this the set-cookie present in response header of call1 is not sent in the request header of call2, and returns 400 response. The same setting is working fine for other browsers chrome & firefox. Is this a bug or DNR works differently for safari ? currently webRequestBlocking works in safari for manifest v3, is there any development of it getting removed just like it's removed in chrome in mv3.