This article is about configuring SSO for your ideas portal. Read these articles if you want to configure SSO for your Aha! Ideas account.
Every organization wants better ideas, but it’s tough to actually capture ideas from customers, employees, and others in a manageable way.
Single Sign-On (SSO) allows your users to log in to your ideas portal using their existing OpenID Connect-enabled identity provider, such as Active Directory, OneLogin, PingIdentity, Okta and many more. With SSO, you can increase engagement of your idea portals as employees and customers no longer need to keep track of yet another email and password.
This article will provide information on how to set up SSO for your public and private idea portals.
OpenID Connect can be complex to configure. For Aha! Ideas portals, it does not provide significant advantages over a traditional SAML configuration. If your identity provider supports both, you may want to review the SAML SSO article as well.
Click any of the following links to skip ahead:
Optional: Configure your OIDC identity provider to send the information that Aha! Ideas needs
Share your SSO configuration between portals (Advanced plan)
How it works
When a user visits your ideas portal, they will see the option to authenticate with SSO. If they have already signed in to your OIDC provider, they are signed in to the portal without any extra steps.
Public portal: Once you configure SSO, users are prompted to sign in before they can post or vote on ideas. Anyone can still view ideas without signing in.
Private portal: Users must sign in via SSO to access the portal. If SSO is configured, any user who can authenticate with your identity provider can access the portal, regardless of email domain.
You can also invite portal users from your ideas portal settings, even if they are not yet configured in your identity provider. However, they will not be able to sign in until they can authenticate with your identity provider.
Enable SSO for any Aha! Ideas portal
You can configure SSO separately for each ideas portal in your account. You will need to be an administrator with customizations permissions to configure an ideas portal.
To begin:
-
Open your portal settings.
From Ideas → Overview, click the pencil icon by the name of the ideas portal you wish to edit.
In the portal settings, go to the Users tab, then scroll to the SSO section.
In the Identity provider dropdown, select OpenID Connect. The OpenID Connect configuration fields appear.
Configure the following fields:
Callback URL: Copy this value from Aha! Ideas and paste it into your identity provider configuration as a login redirect URL.
-
Single sign-on endpoint: In your provider, copy the exact endpoint URL specified by your identity provider and paste it into this field.
The Single sign‑on endpoint value must match the issuer value in your identity provider discovery response.
You can view the discovery response by appending
/.well-known/openid-configurationto the endpoint. For example, if the endpoint ishttps://myprovider.example.com, then the discovery document is athttps://myprovider.example.com/.well-known/openid-configuration.
Identifier (Client ID): Copy the client ID from your identity provider and paste it here.
Secret: Copy the client secret from your identity provider and paste it here.
Below these core fields, you will see additional advanced settings related to CNAME support. These are disabled by default. Most accounts do not need them, and incorrect configuration can break SSO. But if you need help configuring these options, you can reach out to our Customer Success team.
Enable CNAME for SSO URLs: This option is rarely needed and will break SSO if not carefully configured. Only use this if your network policies require all traffic on a custom domain. You must also enter a custom CNAME below to enable this feature.
CNAME: Enter CNAME that matches a custom domain already in use by an active ideas portal in your account. After you add the CNAME, click Update URLs and then save your SSO settings. If you have configured SSO before, you may also need to update these URLs in your identity provider.
Existing Aha! Ideas user accounts and SSO
By default, Aha! Ideas checks whether a user already has an Aha! Ideas login.
If the email address a user enters is not registered in Aha! Ideas, they are directed to sign in with your SSO configuration.
If the email address is registered in Aha! Ideas, they are directed to sign in with their existing Aha! Ideas credentials. This avoids creating two different logins for the same person.
You can change this behavior by clearing the Access for Aha! users option in your portal SSO settings.
When you use SSO, you should manage email addresses in your identity provider. If someone changes a user’s email address in Aha! Ideas, it will reset to the value provided by your identity provider the next time that user signs in.
Configure your OIDC identity provider to send the information that Aha! Ideas needs
In many cases, you can save your OIDC SSO configuration in Aha! Ideas and start using it right away. If your identity provider does not send the required claims, Aha! Ideas shows clear error messages when you save the settings so that you can adjust your identity provider configuration.
The following are required OpenID Connect claims:
email
given_name
family_name
And this is the list of OIDC scopes we request:
openid
email
profile
access token
Aha! uses these attributes to identify users and match them to users in your Aha! account or ideas portal.
How ID tokens and access tokens are used
In an OpenID Connect flow:
The ID token represents the user’s authentication and typically includes identity claims (for example
email,given_name, andfamily_name) when those claims are requested.The access token authorizes calls to protected APIs and resources.
Aha! Ideas requires an access token and an ID token. The access token allows Aha! Ideas to call your identity provider userinfo endpoint. This call retrieves user profile information and helps maintain a consistent and reliable session for each signed‑in user.
Custom API scopes and OpenID B2C behavior
The Aha! Ideas configuration user interface lets you set the standard scopes that we request (openid, email, profile). Some identity providers only return an access token when a specific API or resource scope is requested. Azure AD B2C is one example.
In Azure AD B2C you might see this pattern:
Azure AD B2C returns an ID token that contains all required claims.
Azure AD B2C only returns an access token when an API scope is requested or the application client ID used as a scope.
This behavior follows standard OAuth 2.0 and OIDC design. The access token is issued for a specific resource.
If your provider requires a custom API scope for access tokens, contact our Customer Success team. For compatible providers, we can enable an account capability that allows Aha! Ideas to request an access token by using your application’s client ID as the scope.
Azure AD B2C userinfo endpoint requirements
If you use Azure AD B2C, be aware of a few additional points:
You must use a custom policy. The
userinfoendpoint is available only for custom policies that expose it.Aha! Ideas relies on the
userinfoendpoint together with the access token to complete authentication.
To use OIDC SSO for Aha! Ideas with Azure AD B2C:
Confirm that your B2C policy exposes the
userinfoendpoint.Confirm that your configuration issues both an ID token and an access token that include the required claims.
If you need a custom scope so that Azure AD B2C issues an access token, work with Aha! Customer Success to enable the appropriate account capability.
Share your SSO configuration between portals (Advanced plan)
If your account includes Aha! Ideas Advanced, you can create a shared identity provider and use it across multiple portals. This reduces duplication and makes it easier to maintain SSO settings.
Follow the steps in the Configure OpenID Connect SSO section for your identity provider, such as Azure AD.
In Aha! Ideas, navigate to Ideas → Overview and click the pencil icon by the name of the ideas portal you want to edit.
Go to the Users tab and then the SSO section.
In the Identity provider dropdown, select Add new provider.
-
Enter the following:
Name: Choose a name that makes sense across portals, such as “Employees” or “Customers.”
Type: Select OIDC
Click Save and continue in Aha! and complete the remaining fields.
Click Enable SSO to activate the provider.
To assign this provider to other portals:
Open each portal’s settings.
Go to the Users tab and then the SSO section.
In the Identity provider dropdown, select the shared provider you created.
Save your changes.
You can manage shared identity providers and see which portals use them from the Identity providers tab under User menu → Settings → Account → Ideas portals.
Set contact custom field values
Portal SSO can set idea portal contact custom fields when a user signs in. Your SSO provider (JWT or SAML) sends attributes that map to specific contact custom fields in your Aha! account. Each incoming attribute maps to a contact custom field by its API key and then sets or updates the value on the portal contact. This works for both new and existing portal users.
This capability is useful when you already maintain important user data in your identity provider. You can store an internal user identifier, region, or other key attributes directly on the portal contact. New contacts receive these values at creation. Existing contacts are updated the next time the user signs in, so your Aha! account stays aligned with your source of truth without additional API calls.
To set contact custom field values through portal SSO:
Identify the data you want to sync.
-
Configure custom fields on your contact layout.
Navigate to User menu -> Settings -> Account -> Custom layout.
Edit the contact layout for your account and confirm or create new fields for each attribute you want to sync.
For each field, note the API key exactly as it appears in the configuration. You will use this in your SSO mapping.
-
Map attributes in your SSO identify provider.
Add attributes to the assertion for your portal.
Set each attribute name to match the corresponding contact custom field API key from your Aha! account.
Map each attribute to the correct data source in your identity provider so the value reflects what you want stored in the portal contact.
-
Test with a single user.
Choose a test user in your identity provider and use it to log in to your portal via SSO.
In your Aha! account, open the portal contact record for that user and confirm that the custom fields now contain the expected values.
Troubleshooting
If you run into issues with portal SSO:
Start with the integration log messages for your SSO configuration. They often pinpoint the exact claim or setting that you need to adjust.
Review the list of common SSO configuration issues in our knowledge base. These examples include typical problems with claims, scopes, and redirect URLs.
If you get stuck, please reach out to our Customer Success team. Our team is made up entirely of product experts and responds fast.