Passwords for applications using third-party authentication?

Question

I have an ASP.NET MVC application into which I have just integrated the RPX third-party federated identity system. The integration is working ok, but I'm having some difficulty wrapping my head around what to do with it at the ASP.NET level.

Because the identity is handled externally, I have no need for passwords in my app: I never receive the user's password, just their identity. However, the ASP.NET Membership Provider stuff requires passwords be passed around in order to create a user, sign a user in, etc.

I've been considering using new Guid() at creation time, but this would require a call to the database to retrieve the user's password before I could sign the user in via the membership provider. I could use the same password for each user so that it's known in advance, but I'm concerned that this would make my user's data insecure.

I'd be interested to hear how other sites handle this issue, e.g., StackOverflow.

[Please also see my other question, regarding membership providers for such an app.]

Answer 1

Why use asp.net membership then? It doesn't really fit into you what you are doing which is 3rd party authentication. Maybe you could have a look at the dotnetopenid project and examples as they have a classic asp.net site example which you could modify for mvc? They have a wiki here Maybe google dotnetopenid mvc?

Answer 2

but I'm concerned that this would make my user's data insecure.

Start by ensuring that noone can authenticate directly against your database using a username and password - I imagine this is already the case as you are using RPX to do the actual authentication, and you are only invoking the ASP.NET membership provider once you have already established the user's identity.

Then, the password stored on your side becomes immaterial, because it's not a secret - if I can work out what someone's password is on your side, it doesn't suddenly compromise their data because I still can't login using that information. The user's secret is managed by the 3rd party provider, not you.

So you might as well store what is most convenient (ie a well-known dummy value) - you might as well turn off password encryption as well on the membership provider, to get back some cycles on the server. No point in encrypting / hashing values that aren't used to verify anyone's identity.