I'm splitting off the documentation needs in #817118: Remove {authmap} and migrate OpenID entries to their own table to a new issue.
In a nutshell, the {authmap} table is poorly documented. Most of the confusion results from the unique keys on the authname column. This means that if...
In case multiple external authentication mechanisms are employed, it is possible that an identical authname is defined in more than one external authentication mechanism, and thus an authname occurs twice in the authmap table with two different uids.
The proper use of the authname column is described by Damien:
@Dave Cohen: indeed, you need to use
1234@facebook, not1234. The module column is there to all modules to quickly find all the authentication maps that belong to them (OpenID uses that, for example, to display the list of identifiers you have mapped to your account).This stuff is mostly undocumented, I believe, so starting by documenting it would be great. As far as I know, there are no performance penalty either way, so I see no compelling reason to change that in D7, which is long API frozen.
Comments
Comment #1
bfroehle commentedTagging.
Comment #2
jhodgdonWhere do you propose that this should be documented -- in the database schema?
Comment #3
bfroehle commentedNo, probably in user_set_authmaps(). I haven't figured out the exact wording yet, but the message needs to be that the username (i.e., the value of the 'authname_MODULE' key) needs to be globally unique amongst all external authentication schemes.
Also, since the talk in #817118: Remove {authmap} and migrate OpenID entries to their own table is leaning towards removing this functionality in D8, a note saying
@todo: Remove this function in D8might be a nice warning for developers.