Our system is built using MVC4-EF6-SimpleMembership.
I'm struggling for 2 days now with how to enable an affiliate company website to login to our system.
What I wanted to implement is a simple GET from their site to ours (we would check the request comes from their domain), where they would pass in an encryption or hash of the password along with a username (not hashed/encrypted).
It turns out I don't have an encrypted/hashed password, which I can give them in order to use it and login, nor I have a way to recover the password in order to hash it myself and most importantly to manage to login with it from code.
Also, I didn't find a way to use the encrypted password field inside the webpages_Membership table. I thought that would be the token to send to our affiliate, but can't see any use for it.
Any ideas?
P.S.
I know there's the OAuth possibility, but I'm afraid to loose time figuring this out and then being dependent on the affiliate site. Is this a wrong approach?
Thanks very much for any help.
This whole approach is a really bad idea, and could very easily open your application up to hackers. You really need to learn more about how to handle authentication with trusted third parties if you're going to go forward, even if it costs you time. What it costs you time now it saves you in the long run in liability.
I'm not clear on your use case for them logging in right now. If it's a human being logging in, just provide them "normal" credentials and have them log in normally (i.e. through a web page POST to get a session cookie, etc).
If you are looking for a way for one of their applications to perform actions on someone's behalf (e.g a cron job or to enable integration with their services), then you should look into providing an API (not using a website per se but a REST or SOAP API). There's a number of mechanisms for that as well (Javascript Web Tokens, SAML assertions, etc).
Finally, if you're intending one of your users on their site to authorize their site to pull information about your user, or perform actions based on your user's wishes, then that's the "sweet spot" for OAuth.
Do not go forward with your plan of issuing out hashes of people's passwords. That isn't how the auth works at all, even if it were a good idea to do so. Standards exist for a reason.