Social login is the capability to present a site visitor the option to sign in with their Facebook or Twitter account. Therefore, including permitted Facebook or Twitter data in their AEM member profile.
To include social login, it is required to create custom Facebook and Twitter applications.
While the we-retail sample provides sample Facebook and Twitter apps and cloud services, they are not available on a production website.
The required steps are:
Enable OAuth authentication on all AEM publish instances.
Without OAuth enabled, attempts to log in fail.
Create a social app and cloud service.
To support log in with Facebook:
To support log in with Twitter:
Enable social login for a community site.
There are two basic concepts:
Scope (permissions) specifies the data the app is allowed to request.
Fields (params) specifies the actual data requested using URL parameters.
Social login and the we-retail Facebook sample were developed when the Facebook Graph API was version 1.0.
As of AEM 6.4 GA and AEM 6.3 SP1 social login was updated to work with the newer Facebook Graph API 2.5 version.
For older AEM versions, if you are facing an exception in logs Can’t extract a token from this, upgrade to latest CFP for that AEM release.
For the Facebook Graph API version information, see the Facebook API changelog.
A properly configured Facebook application is required to enable Facebook social login.
To create Facebook application, follow Facebook’s instructions at https://developers.facebook.com/apps/. Changes to their instructions are not reflected in the following information.
In general, as of Facebook API v2.7:
https://<server>:<port>.
https://<server>:<port>.
For development, http://localhost:4503 will work.
Once the application has been created, locate the App ID and App Secret settings. This information is required for configuring the Facebook cloud service.
The Adobe Granite OAuth Application and Provider instance, instantiated by creating a cloud service configuration, identifies the Facebook application and the member group(s) to which the new users are added.
On the AEM author instance, sign in with administrator privileges.
From global navigation, select Tools > Cloud Services > Facebook Social login configuration.
Select the configuration context path.
Context path should be the same as the cloud configuration path that you have selected while creating/editing a community site.
Check if your context path is enabled to create cloud services below it.
Go to Tools > General > Configuration Browser. Select your context and edit properties. Enable Cloud Configurations if not enabled yet.
Create/Edit Facebook cloud service configuration.
Groups may be added or removed at any time. But existing users’s memberships won’t be affected. Auto membership only applies to new users being created post this field update. For Sites where anonymous users are disabled, chose to add users to corresponding community-members group meant for that closed community site.
The result is an Adobe Granite OAuth Application and Provider instance which does not require further modification unless adding additional scope (permissions). The default scope is the standard permissions for Facebook login. If additional scope is desired, it is necessary to edit the OSGI configuration directly. If there are modifications done directly via system/console, avoid editing your cloud service configurations from touch UI to avoid overwriting.
The AEM Communities provider extends the Adobe Granite OAuth Application and Provider instance.
This provider will require editing to:
Allow user updates
Add additional fields within scope
If editing is necessary, on each AEM publish instance:
Sign in with administrator privileges.
Navigate to the Web Console. For example, http://localhost:4503/system/console/configMgr.
Locate AEM Communities Facebook OAuth Provider.
Select the pencil icon to open for edit.
OAuth Provider ID
(Required) Default value is soco -facebook. Do not edit.
Cloud Service Config
Default value is /etc/ cloudservices / facebookconnect
. Do not edit.
OAuth Provider Service Config
Default value is /apps/social/facebookprovider/config/
. Do not edit.
Enable Tags
Do not Edit.
User Path
Location in the repository where user data is stored. For a community site, to ensure permissions for members to view one another’s profile, the path should be the default /home/users/community.
Enable fields
If checked, the Fields listed are specified on the request to Facebook for user authentication and information. The default is deselected.
Fields
When Fields are enabled, the following fields are included when calling the Facebook Graph API. The fields must be allowed within the scope defined in the cloud service configuration. Additional fields may require approval by Facebook. Reference the Facebook Login Permissions section of the Facebook documentation. The default fields added as parameters are:
If any field is added or changed, update the corresponding Default Sync handler configuration to correct the mapping.
Update User
If checked, refreshes user data in the repository on each login to reflect profile changes or additional data requested. Default is deselected.
The next steps are the same for both Facebook and Twitter:
A configured Twitter application is required to enable Twitter social login.
Follow the latest instructions to create a new Twitter application at https://apps.twitter.com.
In general:
Enter a Name that will identify your Twitter application to the users of your website.
Enter a Description.
For website - enter https://<server>
.
For Callback URL - enter https://server
.
It is not necessary to specify the port.
For development, https://127.0.0.1/ will work.
Once the application has been created, locate the Consumer (API) Key and Consumer (API) Secret. This information will be needed for configuring the Twitter cloud service.
In the Twitter application management’s permissions section:
Access: Select Read only
.
Additional Permissions: Optionally choose Request email addresses from users
.
The only REST request made for social login is to GET account/verify credentials.
The Adobe Granite OAuth Application and Provider instance, instantiated by creating a cloud service configuration, identifies the Twitter application and the member group(s) to which the new users are added.
On the author instance, sign in with administrator privileges.
From global navigation, select Tools > Cloud Services > Twitter Social login configuration.
Choose the context path configuration.
The Context path should be the same as the cloud configuration path that you selected while creating/editing a community site.
Check if your context path is enabled to create cloud services below it.
Go to Tools > General > Configuration Browser. Select your context and edit properties. Enable Cloud Configurations if not enabled yet.
Create/Edit Twitter cloud service configuration.
Title
(Required) Enter a display title that identifies the Twitter App. It is recommended to use the same name entered as the Display Name for the Twitter app.
Consumer Key
(Required) Enter the Consumer (API) Key for the Twitter app. This identifies the Adobe Granite OAuth Application and Provider instance created from the dialog.
Consumer Secret
(Required) Enter the Consumer(API) Secret for the Twitter App.
Create Users
If checked, logging in with a Twitter account will create an AEM user entry and add them as a member to the selected user group(s). Default is checked (strongly recommended).
Mask User IDs
Leave deselected.
Add to User Groups
Select Add User Group to choose one or more member groups for the community site to which users will be added.
Groups may be added or removed at any time. But existing users’ memberships won’t be affected. Auto membership only applies to new users being created post this field update. For Sites where anonymous users are disabled, add users to corresponding community-members group meant for that closed community site.
Select SAVE and Publish.
The result is an Adobe Granite OAuth Application and Provider instance which does not require further modification. The default scope is the standard permissions for Twitter login.
The AEM Communities configuration extends the Adobe Granite OAuth Application and Provider instance. This provider will require editing to allow user updates.
If editing is necessary, on each AEM publish instance:
Sign in with administrator privileges.
Navigate to the Web Console.
For example, http://localhost:4503/system/console/configMgr.
Locate AEM Communities Twitter OAuth Provider.
Select the pencil icon to open for edit.
(Required) The default value is soco -twitter. Do not edit.
Cloud Service Config
The default value is conf. Do not edit.
OAuth Provider Service Config
The default value is /apps/social/twitterprovider/config/
. Do not edit.
User Path
Location in the repository where user data is stored. For a community site, to ensure permissions for members to view one another’s profile, the path should be the default /home/users/community
.
Enable Params do not edit
URL Parameters do not edit
Update User
If checked, refreshes user data in the repository on each login to reflect profile changes or additional data requested. The default is deselected.
The next steps are the same for both Facebook and Twitter:
Once a cloud service is configured, it may be enabled for the relevant Social Login setting for a community site using the User Management Settings sub-panel during community site creation or management.
Choose your site configuration context where you saved your social login configurations.
On General tab, set cloud configurations.
On Settings tab, enable Social Logins and Save.
The Adobe Granite OAuth Authentication Handler
is not enabled by default and must be enabled on all AEM publish instances.
To enable the authentication handler on publish, simply open the OSGi config and save it:
Adobe Granite OAuth Authentication Handler
.Be careful to not confuse the authentication handler with a Facebook or Twitter instance of Adobe Granite OAuth Application and Provider.
When a cloud service for Facebook or Twitter is created, an instance of Adobe Granite OAuth Authentication Handler
is created.
To locate the created instance for a Facebook or Twitter app:
Sign in with administrator privileges.
Navigate to the Web Console.
For example, http://localhost:4503/system/console/configMgr.
Locate Adobe Granite OAuth Application and Provider.
Locate the instance where Client ID matches the App ID.
Except the following properties, leave the other properties of the config unaltered:
Config ID
(Required) OAuth configuration IDs must be unique. Auto-generated when cloud service is created.
Client ID
(Required) The application ID provided when the cloud service was created.
Client Secret
(Required) The application secret provided when the cloud service was created.
Scope
(Optional) Additional scope for what is permitted can be asked from the provider. The default scope covers the permissions necessary for providing social authentication and profile data.
Provider ID
(Required) The provider ID for AEM Communities is set when the cloud service was created. Do not edit. For Facebook Connect, the value is soco -facebook. For Twitter Connect, the value is soco -twitter.
Groups
(Recommended) One or more member groups to which created users are added. For AEM Communities, it is recommended to list the member group for the community site.
Callback URL
(Optional) URL configured with the OAuth providers to redirect the client back. Use a relative url to use the host of the original request. Leave empty to use the originally requested URL instead. Suffix “/callback/j_security_check” is automatically appended to this url .
The domain for the callback must be registered with the provider (Facebook or Twitter).
For each OAuth authentication handler configuration, there are two additional configurations created in the instance:
For more information, see Authentication with Apache Oak External Login Module.
For community sites that see hundreds of thousands of users register using their Facebook or Twitter login, the traversal performance of the query performed when a site visitor uses their social login can be improved by adding the following Oak index.
If traversal warnings are seen in the logs, it is recommended to add this index.
On an author instance, signed in with administrative privileges:
From global navigation: select Tools, CRX/DE Lite.
Create an index named ntBaseLucene-oauth from a copy of ntBaseLucene:
/oak:index
ntBaseLucene
/oak:index
ntBaseLucene-oauth
Modify the properties of node ntBaseLucene-oauth:
/oak:index/ntBaseLucene-oauth
oauthid-123****
true
1
Under node /oak:index/ntBaseLucene-oauth/indexRules/nt:base/properties:
Delete all child nodes, except for cqTags.
Rename cqTags to oauthid-123****
Modify the properties of node oauthid-123****
oauthid-123****
Select Save All.
For the name oauthid-123
, replace 123 with the Facebook App ID or Twitter Consumer (API) Key that is the value of the Client ID in the Adobe Granite OAuth Application and Provider configuration.
For additional information and tools, refer to Oak Queries and Indexing.
See Configuring Dispatcher for Communities.