that's not how it works. the step 4 should be more like: the continue button forwards the client with temporary code (usually in query string), that can be used

that's not how it works. the step 4 should be more like: the continue button forwards the client with temporary code (usually in query string), that can be used to request token, with combination of additional secret token (that should remain private/secret), by backend application. the client never sees the final token, unless the SiteA returns the token to the client, or the exchange of the code happens on the client side. in both cases these are the definitions of incorrect implementation, as the exchange should take place in the backend. in most implementation you can/should send additional parameters like `nonce` or `state`, which can/should be used to protect against reply/forgery attacks.