I'll try to make the explanation simple and to the point (keyword try). And if that's not sufficient, then maybe I can expand on the question.
Imagine two sites:
www.example.com. I only have direct control over resources.example.com. www.example.com ultimately wants access to
resource.example.com/dashboard. The idea here is the resource should be protected; secured.
I also cannot validate www.example.com user credentials for authentication (i.e. username, password). I don't have access to their user store. Ultimately, above all else, my priority is ensuring that www.example.com is the identity of the resource requester.
My first thought was having www.example.com issue a CORS request to resources.example.com for
authorization and send back a
token. Token expiry is small (<5 seconds). I check that the request is POST, validate the origin header and the referrer, if it exists. If no origin header is passed, authorization fails. User then passes back token with standard POST request to resources.example.com/dashboard.
The problem is this is a very bad authorization scheme. Origin header is resistant to spoofing but it absolutely can be spoofed. Referrer is even easier to bypass.
www.example.com wants to keep effort minimal, which probably means it's up to me to code their piece because I don't know if there's a simple solution here. They are open to CORS request.
My question is how can I secure the resource on my site in a CORS request and ensure the identity of the client is www.example.com, knowing the origin header can be spoofed?
Is there some way I can possibly leverage, i.e. a
JSON Web Token (JWT) using
asymmetric cryptography in order to prove the identity of the requester is www.example.com, even if the origin header is compromised? If so, who would generate the JWT, me or www.example.com?