I have implemented a PKCE-flow for my SPA. I'd like to keep the SPA state "alive", and not have the browser leave the SPA, go to the STS, and then come back into the SPA. I therefore use an IFRAME.
This brings me the challenge of communicating the received access code on the callback URL (the IFRAME) to the SPA application. Already using the Broadcast Channel API in other parts of my application, I found that communicating it over this channel to the SPA works very well.
I know that an SPA is untrusted, and I always treat it as such. This is why we have refresh tokens. As far as I can reason, the broadcast is no extra risk. But I am not so sure about the broadcasting channel itself, maybe it could be eavesdropped on? But even if it is, the refresh-token mechanic deals with leaking of the access token, right?
There are a couple of issues with your flow:
Requests during the STS authentication flow are protected by a cookie. When running in an iframe this will be categorized as cross-site and is likely to be dropped according to RFC6265bis. In a same domain employment you'll be be OK though.
Cross site scripting vulnerabilities can enable malicious code to intercept the access token in the same way your code does. The OAuth for Browser Based Apps Doc has a section on JavaScript threats and XSS exploits.
For example, if you had an XSS exploit, malicious code could create its own BroadcastChannel onMessage handler, capture an access token and potentially exfiltrate it from the browser, for a more concerted attack against your APIs. Stakeholders could ask difficult questions about such threats.
These days users are socialized to being redirected to login. Also, if you use HTTP-only cookies rather than tokens in the browser your app will be perceived to be more secure. One option is to use a utility API to issue cookies on behalf of the SPA, eg the token handler pattern.