In step 3, rather than thinking of a "public key", think of a "session token". Specifically, A redirects to B with
http://b.application.com?token=123-3-2-1-3-2-2-1-2-32-3-5-2-4-5245
Tokens should be unique and short-living.
B then contacts A directly and asks about the identity behind the session token:
http://a.application.com/userservice/getuser/123-3-2-1-3-2-2-1-2-32-3-5-2-4-5245
Because B contacts A directly, there is no way for users to forge invalid tokens - a random token just points to non-existing session at A.