Null column for username and password when using Login with *social network* I want to know what are the conventions for columns like username and password when your application supports login with a third party, like login with facebook for instance.

Given the fact that when you Log with a 3rd party, you don't really need to specify a username, you'll just specify the 3rd party user id, in database design, you can expect either a blank field or a null value.

Since usernames are UNIQUE, I'm guessing going for nullable is the way to go, since it allows multiple null columns.

The real issue is that the user needs to specify either a username OR a 3rd party id. Which means both columns can be null, but not at the same time

So what's the convention for handling this design pattern?
I'd rather separate user and authentication mechanism/provider. Application may allow more than one authentication provider (say , logins with facebook, openid, etc). Adding columns/constraints every time you add a new authentication option doesn't sound like a very good idea to me (even though that doesn't happen often, such an action usually requires lots of changes on application side).
Something like 

user(user_id);
authenticator (authenticator_id, name, description, authentication_type);
user_authentication(user_id, authenticator_id, authentication_identity, authenticator_token) ;


seems more general to me. 

** In case of username/password authentication you can keep username in authentication_identity and password (surely not plain text) in authenticator_token. If you feel the pair authentication_identity/authenticator_token doesn't cover all the cases you can add couple more tables that store information specific to particular authentication_type