I think steps 3 and 4 are not quite right. I’ve edited your example to show how I think the attack works.
1.Mallory visits some client’s website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook – as brilliantphotos.com allows its users to post pictures to their Acebook page)
2.brilliantphotos.com redirects Mallory’s browser to Acebook’s Authorisation Server requesting a redirect back to itself once auth is done.
3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.
4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.
https://brilliantphotos.com/exchangecodefortoken?code=malloryscode
5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post…) note that Alice may already be logged-in to brilliantphotos.com with her own account.
6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory’s account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice’s account with the newly minted access token.
7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory’s account on the service provider (Acebook).
If a state parameter was maintained by brilliantphotos.com then Mallory’s state code would be bound to her browser but not Alice’s. Therefore brilliantphotos.com would not be able to correlate the state code with Alice’s browser session when Alice clicks on the malicious URL.