Identity Provider Configuration: Amazon Cognito
IDP Reference Resources
- https://docs.aws.amazon.com/cognito/latest/developerguide/open-id.html
- https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html
- https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html
- https://medium.com/@robert.broeckelmann/openid-connect-authorization-code-flow-with-aws-cognito-246997abd11a
The settings outline in this guide are a starting point reference of a known working Amazon Cognito OpenID Connect Client configuration for the OpenID Connect Generic plugin provided by the user community. As with all Identity Providers many other configuration options within the platform could effect how these settings work.
Annotations:
- Click the button "Create user pool" as shown below
For this exercise, we stick with the default Cognito User Pool.
Annotations:
- You may add Federated identity providers such as Google or Facebook at a later time after the creation of user pool.
- WordPress exposes usernames in author profile pages (https:// www.domain.com/author/user_nicename). Hence I choose to allow only Email as the Login option. If your needs are different, you must choose appropriate options right here. This cannot be edited after user pool has been created.
Annotations:
- Password Policy: You may leave this as the Cognito default value.
- Multi-factor Authentication: For ease of demonstration, I have opted for "No MFA".
- Since I am not capturing phone number during registration, I have opted for default selections to enable self-service account recovery via email
- All these options are configurable even after user pool has been created
Configuring Sign Up Experience (Self Service, Account Confirmation, and Mandatory Attributes) for the User Pool
Annotations:
- Self-service sign-up: I am testing for use cases like multi author blogs, WooCommerce, and Membership sites and hence enabled self-registration here
- "Attribute verification and account confirmation": Use the default values under this section
- Required Attributes: On WordPress I need a username and a display name. Therefore, during signups, in addition to the default "email", users will provide the mandatory attributes of "preferred_username", and ["given_name" plus "family_name"] to construct the display name. Note - You can not edit required attributes after user pool has been created.
Annotations:
- You must have an active AWS SES account to configure this section.
- Configuration tips of AWS SES are beyond the scope of this exercise. However, you will find many resources online.
Annotations:
- Provide appropriate names for user pool, hosted domain, and client name
- Choose app type as Public client
- Client Secret: Choose the option "Don't generate a client secret". Note: Although AWS expects our WordPress plugin to provide a secret, do NOT generate one here (in my limited tests, generating client secret here failed). Instead, generate a random key at Lastpass and use it in the plugin configuration.
- Allowed Callback URLs: The plugin OpenID Connect Generic Client provides a redirect URL. Use it here as the Callback URL. Typically, its in the format of https:// www.domain.com/openid-connect-authorize
Annotations:
- Authentication Flows: Out of the default authentication flows, deselect (X) the Lambda trigger based authentication flow of "ALLOW_CUSTOM_AUTH" and retain the rest two as shown below. The WordPress integration works without the "ALLOW_CUSTOM_AUTH". Hence removed.
- OpenID Connect Scopes: From the default, I removed (X) the scope of "Phone" number (since I am not using it) and added "Profile". If you use a different set of attributes, select the scope appropriately.
Annotations:
- These are a set of permissions of what our WordPress plugin can read and write in AWS Cognito user pool. Deselect everything else except the required registration attributes.
- Note: Since AWS Cognito forces apps to have write permissions on these, I have also granted read permissions on "email_verified" and "phone_verified" attributes for my WordPress app.
Annotations:
- Review all contents of this screen.
Annotations:
- When everything looks good, click "Create user pool" button.
Annotations:
- To test the Cognito hosted page -> Click on the newly created user pool
Annotations:
- To test the Cognito hosted page -> Navigate to the App Integration tab and click on the App name
Annotations:
- To test the Cognito hosted page -> Scroll to the Hosted UI section and click on button "View Hosted UI"
Annotations:
- If you see the default screen below, your app's hosted page is created successfully.
Configuration of WordPress Plugin - OpenID Connect - Generic Client for AWS Cognito
Annotations:
- This configuration is tested on version 3.9.0
- Client ID: Copy the client ID from the app screen of AWS Cognito's user pool and paste it here
- Login Endpoint: https://{hosteddomainname.url}/oauth2/authorize
- Token Validation: https://{hosteddomainname.url}/oauth2/token
- End Session Endpoint: https://{hosteddomainname.url}/oauth2/logout
- userInfo Endpoint: https://{hosteddomainname.url}/oauth2/userInfo | Note: Do NOT copy the URL string from plugin example (in version 3.9.0) tip shown underneath this field, As documented by AWS, the User Info endpoint URL is case-sensitive. As per AWS, the userInfo part of the string "/userInfo" has only the I capitalized. So, if you use UserInfo (both U and I capitalised) or userinfo (both u and i as lowercase), you would see an error "Invalid User Claims" discussed here. Aside, the integration should also work if you leave this field blank. But I am not sure whether that's a good way to proceed.
- In all the above Endpoint URLs, replace the string {hosteddomainname.url} with the actual hosted domain URL from AWS Cognito
- Rest of the configuration is self-explanatory and some of it is marked on the image below
- Once you click save and save the permalinks, embed the button shortcode on a sample page. Then from the frontend, click that button. If you are taken to the Cognito hosted UI screen shown in Screenshot 8(d), try registering a user. If you have followed the steps herein, chances are, the new user would be automatically logged in after registration.
- To hide the "login' button for logged-in users, you may use any page designer plugin that supports conditional visibility. I have successfully tested conditional visibility of this button with WP Stackable Gutenberg plugin. This is also discussed here.
