I am not a security expert, so I am hoping that a few of you might be able to tell me if there are any gaping flaws in the security design for my web app. Hopefully I'll be able to explain this clearly enough to get my point across.
I have a website which makes calls to my api. Both use SSL and are hosted in Azure, but have different domains / servers. I am also using ASP .Net Identity 2.0 and OAuth bearer tokens, with a 30 day expiration, to track whether or not a user is "logged-in".
Users can log-in either via the main website, or by using a widget which can be added to ANY 3rd-party site.
To keep things secure, the widget creates an iframe which points to a page on my api server, and all functionality, such as login and transaction processing takes place within this iframe.
The parent page uses postMessage to communicate with the iframe when something needs to happen, but to prevent anything on the parent page from getting access to that token, it only exists within the iframe's local/session storage and is never communicated back up the stack.
So far this all seems to be working as intended, but I've run into a scenario where I now need to communicate the token back to the parent for code running on my website. However, I'm hesitant to do this, as it potentially creates a security hole.
Does anyone have any thoughts on whether this is an acceptable risk for code I control, or if there are any issues with the general approach I've taken?