# OpenID ## Backend class For Django, add this class path to `AUTHENTICATION_BACKENDS`. For other integrations, use the same class path in the framework-specific backend setting. | Backend name | Class path | |----------------|-------------------------------------------| | `openid` | `social_core.backends.open_id.OpenIdAuth` | [OpenID](http://openid.net/) support is simpler to implement than [OAuth](http://oauth.net/). Google and Yahoo providers are supported by default, others are supported by POST method providing endpoint URL. The generic OpenID backend stores the identity URL asserted by the provider as the user’s unique identifier. Because this identifier is protocol-derived rather than selected from a response mapping, the generic `ID_KEY` setting does not apply. [OpenID](http://openid.net/) backends can store extra data in `UserSocialAuth.extra_data` field by defining a set of values names to retrieve from any of the used schemas, AttributeExchange and SimpleRegistration. As their keywords differ we need two settings. Settings is per backend, so we have two possible values for each one. Name is dynamically checked using uppercase backend name as prefix: ```default SOCIAL_AUTH__SREG_EXTRA_DATA SOCIAL_AUTH__AX_EXTRA_DATA ``` Example: ```default SOCIAL_AUTH_GOOGLE_SREG_EXTRA_DATA = [(..., ...)] SOCIAL_AUTH_GOOGLE_AX_EXTRA_DATA = [(..., ...)] ``` Settings must be a list of tuples mapping value name in response and value alias used to store. A third value (boolean) is supported to, it’s purpose is to signal if the value should be discarded if it evaluates to `False`, this is to avoid replacing old (needed) values when they don’t form part of current response. If not present, then this check is avoided and the value will replace any data. ## Username The [OpenID](http://openid.net/) backend will check for a `username` key in the values returned by the server, but default to `first-name` + `last-name` if that key is missing. It’s possible to indicate the username key in the values If the username is under a different key with a setting, but backends should have defined a default value. For example: ```default SOCIAL_AUTH_FEDORA_USERNAME_KEY = 'nickname' ``` This setting indicates that the username should be populated by the `nickname` value in the Fedora [OpenID](http://openid.net/) provider.