OpenID Connect (OIDC) Single Sign-On (SSO) simplifies secure user authentication by connecting your app to an Identity Provider (IdP) like Google, Okta, or Azure AD. It uses JSON Web Tokens (JWTs) to verify user identity and provide profile details, streamlining access across multiple apps with one login. Here's how you can set up OIDC SSO in Adalo Blue:
- What You Need: Administrative access to an OIDC-compatible IdP (e.g., Okta, Auth0) and an Adalo Blue Team ($200/month) or Business plan ($250/month).
- Setup Overview:
- Register Adalo Blue in your IdP and gather the Client ID, Client Secret, and Discovery Endpoint.
- Configure Adalo Blue with these details and map user claims (e.g.,
email,sub) to app properties. - Test the connection using Adalo Blue's built-in tools to ensure proper authentication.
- Activate SSO and share the login URL with your team.
Pro Tip: Use the Authorization Code Flow for secure authentication and ensure the openid, email, and profile scopes are enabled. Keep your configuration updated by regularly rotating keys and monitoring IdP settings.
This guide walks you through each step, from configuring your IdP to testing and activating SSO in Adalo Blue, ensuring a smooth and secure integration.
OpenID Connect SSO Setup Process for Adalo Blue
Prerequisites for Setting Up OIDC SSO in Adalo Blue
Required Accounts and Permissions
To set up OIDC SSO in Adalo Blue, you’ll need administrative access to an account on either the Team plan ($200/month) or the Business plan ($250/month). These plans include the SSO functionality required for integration. Note that the Professional plan ($65/month), while offering advanced API integration, doesn’t support full SSO features.
Additionally, you must have administrative access to an OIDC-compatible Identity Provider (IdP) like Okta, Auth0, or Azure AD. This access allows you to create integrations, configure redirect URIs, and generate client credentials. Once you’ve confirmed your permissions and accounts, you can start gathering the necessary details from your IdP.
Information You'll Need from Your IdP
After registering Adalo Blue as an application within your IdP, collect these critical pieces of information:
- Client ID: This is the public identifier for your application.
- Client Secret: A private key used to authenticate Adalo Blue with your IdP. Treat this like a password and keep it secure.
- Discovery Endpoint: Usually ends with
/.well-known/openid-configurationand provides configuration details automatically.
To ensure everything is set up correctly, paste the Discovery Endpoint URL into a browser. It should return a JSON object with connection metadata. Confirm that your IdP is configured to share the openid, profile, and email scopes - these are required for mapping user claims properly in Adalo Blue. Once you’ve gathered these details, you’re ready to move on to configuring Adalo Blue.
Adalo Blue Configuration Access
With your IdP details in hand, log into Adalo Blue to begin the SSO configuration. Head to the Settings section (look for the magic wand icon in the sidebar) to access the SSO setup options. Here, you’ll find integration and security settings where you can input your IdP credentials and manage authentication protocols.
Adalo Blue will provide a Redirect URI in its settings. Copy this URI and paste it into your IdP’s application settings to ensure authentication responses are routed to the correct endpoint. Double-check that all your IdP details are prepared before diving into Adalo Blue’s configuration panel.
How to Configure OpenID Connect SSO
Configure Your Identity Provider (IdP)
Begin by logging into your Identity Provider (IdP) account with administrative access. Whether you're using Okta, Auth0, Azure AD, or another OIDC-compatible provider, the setup generally follows a similar process. First, create a new application integration, select OIDC – OpenID Connect as the sign-in method, and choose Web Application for the application type.
Next, select the Authorization Code grant type. This flow is highly recommended for web-based integrations like Adalo Blue, as it ensures secure server-side authentication. From your Adalo Blue dashboard, copy the callback URL and paste it into your IdP's "Sign-in redirect URIs" field. This URL is critical - it directs the IdP to send users back to your app after successful authentication.
You'll also need to configure the required scopes. At a minimum, include the openid scope along with profile and email to ensure that the IdP shares essential user information. Once you save the application, your IdP will generate a Client ID and Client Secret. Be sure to copy these values immediately, as you’ll need them for the next step.
Enter OIDC Details in Adalo Blue
Head over to the Settings section in Adalo Blue by clicking the magic wand icon in the sidebar. Locate the SSO configuration panel, where you'll find fields for entering your Client ID, Client Secret, and Issuer URL. Paste the Client ID and Client Secret from your IdP into the respective fields. Remember, the Client Secret is sensitive information - treat it like a password and avoid sharing or storing it insecurely.
For the Issuer URL, use your IdP's discovery endpoint, which typically ends with /.well-known/openid-configuration. This URL allows Adalo Blue to automatically retrieve and configure key endpoints, such as Authorization, Token, and UserInfo, reducing the risk of manual errors. Double-check that the redirect URI in Adalo Blue matches exactly with the one you entered in your IdP - any inconsistency, even minor, can lead to authentication issues. Once these details are entered, proceed to map user claims and roles to finish the setup.
Map User Claims and Roles
The final step is mapping user attributes from your IdP to Adalo Blue's user properties. When a user logs in, the IdP sends an ID token containing claims - verified pieces of information about the user.
In Adalo Blue's SSO settings, locate the Username claim key field. This determines which claim from the IdP will serve as the user's unique identifier. Common options include sub or email. To confirm which claim your IdP sends, enable the Preview claims feature. This tool allows you to inspect the claims being sent, ensuring the information aligns with your system's requirements.
| OIDC Claim | Adalo Blue User Property | Description |
|---|---|---|
sub |
User ID / Unique Identifier | The unique identifier for the user |
email |
The user's verified email address | |
given_name |
First Name | The user's first or given name |
family_name |
Last Name | The user's last or family name |
groups |
Roles / Permissions | Optional claim for role-based access control |
If your app requires role-based access control, configure your IdP to include a groups or roles claim in the ID token. Adalo Blue can use this claim to automatically assign permissions to users upon login. Keep the Preview claims feature enabled during the initial setup to verify that everything is mapped correctly. Once you're confident the configuration is accurate, you can disable the preview feature for regular use.
Test and Activate OIDC SSO in Adalo Blue
Use Adalo Blue's SSO Testing Tool
Before rolling out SSO, it's crucial to test the connection in a controlled environment. Head to the Test Connection tab in the Adalo Blue SSO configuration dashboard and click Test Login. This will simulate an SSO flow, opening a new window that displays the connection status, highlights any issues, and shows the full response from your Identity Provider (IdP).
The testing tool provides detailed information about the claims sent by your IdP. These include standard attributes like sub, email, and name, as well as any custom roles you've set up. Carefully review this data to confirm that all mappings are accurate. Rest assured, testing won't affect your permissions.
If the IdP sends a "thin token" with incomplete user information, the test results will flag this issue. To address it, configure a UserInfo endpoint (also called a Fat Token URL) to retrieve the full user profile.
Make sure to resolve any issues identified during testing before moving on to activation.
Troubleshoot Common Issues
When the test connection fails, the tool provides specific warnings to help you pinpoint the problem. One frequent issue is a mismatched Redirect URI - even a small typo or extra character can disrupt authentication.
| Common Issue | Likely Cause | Troubleshooting Step |
|---|---|---|
| Invalid Redirect URI | Mismatch between IdP and Adalo Blue | Ensure the URI matches exactly in both dashboards |
| Missing User Data | Incorrect or missing scopes | Verify openid, email, and profile scopes are requested |
| Incomplete Profile | Thin ID tokens from the IdP | Configure a UserInfo (Fat Token) URL |
| Role Sync Failure | Case sensitivity or invalid role names | Match IdP role strings exactly to expected values |
| 404 on Metadata | Incorrect discovery endpoint | Ensure the URL ends with /.well-known/openid-configuration |
Double-check that the IdP application includes the necessary openid, email, and profile scopes. Test the discovery URL in your browser to confirm it returns JSON metadata. Pay close attention to role mapping, as it's case-sensitive - role names must match exactly. When testing role assignments, start with a non-admin account to avoid accidentally locking yourself out of administrative access.
Once all issues are resolved, you're ready to activate SSO.
Activate OIDC SSO for Your Team
After passing all tests, activate SSO by toggling the Allow SSO authentication switch in the settings panel. Double-check role mappings to ensure they won't overwrite any manual assignments.
Next, log out and test the SSO flow to confirm everything works as expected. Once verified, share the unique SSO login URL with your team.
To avoid being locked out during rollout, keep a secondary administrative login method active until you're confident that multiple team members can successfully authenticate via SSO. This precaution ensures a smooth transition for your team.
sbb-itb-d4116c7
How to Setup Single Sign-On using OIDC and OAuth2.0 within Entra ID with third-party apps
Best Practices for Secure and Scalable OIDC SSO
Once your OIDC SSO setup is tested, it's time to strengthen and expand your integration with these essential practices.
Secure Your Configuration
Protect your secrets by implementing regular key rotation. To rotate keys, generate a new secret in your Identity Provider (IdP), update it in Adalo Blue, and then deactivate the old secret promptly.
For mobile and browser-based apps, always use the Authorization Code Flow with PKCE. This helps prevent token interception during the authentication process. Additionally, limit your redirect URIs to exact, absolute URLs. Avoid using wildcard subdomains, as they can expose your system to token redirection attacks by malicious actors.
Request only the necessary scopes, such as openid, email, and profile. For applications meant for internal use, you can enhance security by restricting logins to your organization's email domain. This simple measure blocks unauthorized external access.
Keep SSO Settings Updated
Identity Providers like Okta often rotate their signing keys every 90 days, though this schedule can vary. To stay ahead, periodically query the /.well-known/jwks.json endpoint to update public keys. Use the /.well-known/openid-configuration discovery endpoint to automate updates for settings like authorization and token endpoints. This minimizes manual errors and ensures your configuration stays current.
Create a routine for rotating client secrets and reviewing your configuration settings. A quarterly schedule works well for most organizations, but you may need to increase the frequency if there are signs of credential exposure. During peak usage, monitor your IdP's rate limit headers (e.g., X-Rate-Limit-Remaining) to avoid service disruptions.
With your setup secure and regularly updated, you can turn your attention to scaling SSO for broader enterprise use.
Scale SSO for Enterprise Use
Leverage the groups claim to map user roles in Adalo Blue, which simplifies access control as your user base expands. If a user belongs to multiple groups, consider implementing a priority system where higher-level roles, such as Org Admin, automatically override lower-level roles.
For B2B applications serving multiple organizations, assign unique OIDC client credentials to each customer. Avoid a single global credential system, as it can complicate management and reduce security. If you're handling a diverse user base, implement Home Realm Discovery (HRD). This feature routes users to their specific enterprise IdP based on their email domain, making the login process seamless.
| Security Feature | When to Use | Key Benefit |
|---|---|---|
| PKCE | Mobile & single-page apps | Prevents authorization code interception attacks |
| Group Claims | Enterprise scaling | Automates role-based access control |
| Domain Filtering | Internal/B2B apps | Limits access to authorized users only |
Conclusion
By following the steps outlined earlier, OpenID Connect (OIDC) Single Sign-On (SSO) ensures secure and efficient access for your app.
Integrating OIDC SSO with Adalo Blue simplifies authentication through providers like Azure AD, Okta, or Google. The setup process includes registering your app with an Identity Provider (IdP), configuring redirect URIs, and aligning user claims with your database properties. Once everything is in place, users enjoy one-click access, and centralized identity management simplifies user provisioning.
OIDC employs modern security protocols like multi-factor authentication and PKCE, helping to mitigate security risks while reducing IT workload.
For enterprise teams, a single configuration supports seamless access across web, iOS, and Android platforms, delivering a consistent experience for users. Automated role mapping and scalable configurations make it easy to manage growth without additional complexity.
"Single sign-on represents a technology offering numerous benefits, including cost savings for IT, heightened employee job satisfaction, and an enhanced customer experience." - Explorance Blue
With the right OIDC SSO configuration, your app achieves secure, streamlined access for users, centralized control for IT teams, and enterprise-level security - laying the groundwork for sustained growth.
FAQs
What makes the Authorization Code Flow with PKCE more secure for OIDC SSO?
The Authorization Code Flow with PKCE adds an extra layer of security to OpenID Connect Single Sign-On (OIDC SSO). By doing so, it protects against authorization code interception attacks, ensuring that only the intended client application can use the authorization code.
This method is especially helpful for public clients like single-page applications. It allows for secure token exchanges without revealing sensitive data, reducing the chances of token leakage or unauthorized access. This makes it a dependable approach to protecting user authentication.
How do I resolve common issues when setting up OIDC SSO in Adalo Blue?
To address common challenges during the OpenID Connect (OIDC) SSO setup in Adalo Blue, start by reviewing your configuration settings. Make sure the redirect URL is an exact match between your Identity Provider (IdP) and Adalo. Double-check that your client ID, client secret, and all endpoint URLs - such as authorization, token, and user info - are entered correctly.
If you run into errors, carefully examine the error messages for helpful details. Issues like unrecognized logins might require you to whitelist your IdP URL or confirm that trusted domains are properly configured in your settings. Testing in an incognito browser can also be useful to rule out any interference from cached data or cookies.
For more in-depth guidance, explore Adalo's support resources or consult your IdP documentation to verify your setup and address specific problems.
How can I keep my OpenID Connect Single Sign-On (SSO) setup secure and up-to-date?
To maintain the security and reliability of your OpenID Connect SSO setup, it’s crucial to periodically update client credentials like client IDs and secrets. This helps reduce the risk of unauthorized access. Additionally, ensure you have robust token validation and claim verification processes in place to confirm both user authenticity and their permissions.
Keep yourself updated on security guidelines and updates provided by your identity provider. Regularly review their documentation and apply any recommended changes to address vulnerabilities and strengthen your system’s security.
Related Blog Posts
