You'd need to have their login information for application B available to you in application A. Which means that your users would have to tell you how to log in to application B for them ... which strikes me as a thing you're unlikely to get people to do. Even if you could, that's a really bad solution. For one, can you guarantee that user "artist" on your application is the same individual as "artist" on their application?

Assuming you can't just unify the user databases and authentication mechanisms for applications A and B (this is a "single sign-on" scheme), you could to try to work something out with the maintainers of the other application that involves them trusting your application that when your application says this is user X, it really is who they'd call user X. But that seems unlikely, since (for example) you won't be able to guarantee that user names are the same across the application. Even if you found a way around that, can you guarantee that your users can't spoof their names on the other application?

Changing protocols to SOAP (assuming you can get the maintainers of B to expose those services) is a good idea in the abstract, but it doesn't solve this fundamental problem. There is no purely programmatic solution to this problem that you can implement by yourself. Well, none that's ethical, anyhow.