At the OutSystems NextStep Experience (ONE) conference 2025 in Lisbon, OutSystems announced that every O11 customer can add an extra OutSystems Developer Cloud environment to their subscription. Most importantly, OutSystems 11 no longer has an end-of-life date.
OutSystems puts a lot of effort into making interoperability as easy as possible. As of now (Feb 2026), it's already possible to connect OutSystems 11 data (Entities) to ODC for both reading and writing, with more features on the way. Watch the Platform Interoperability on-demand webinar for an overview.
One of the still upcoming features is Identity Integration, which will let OutSystems 11 users sign in to ODC applications. Meanwhile, community members have already started asking on the forum about the easiest way to connect users with ODC.
That's why I created a component, essentially a Mini Identity Provider, for OutSystems 11. You can use it right away to connect your OutSystems 11 user base to ODC by adding a new Identity Provider in ODC Portal.
When You Should Care
This article and the Forge component are relevant to you if you're using the default username/password authentication method in the OutSystems 11 Users Provider. This includes any custom modifications you've made.
It doesn't apply if you're already using an external Identity Provider like Microsoft Entra, Auth0, or others.
💡
I was quite surprised that so many O11 environments use the built-in default authentication method instead of an external, professional identity provider. I might be strict in this view, but I can't think of any situation where this makes sense. You either miss out on many features of a dedicated solution, like single sign-on, multi-factor authentication, conditional access, anomaly detection, and more, or you'd have to build it yourself (which is possible, of course).
If you are using OutSystems 11's default authentication and want your users to sign in to ODC with their O11 account, this article and component might be useful for you, even after OutSystems releases the official identity integration. OutSystems might not cover every possible edge case or your specific identity integration needs right away. In that case, you can use the component to tailor it to your needs and later transition smoothly to the official integration.
Besides all this, you may learn some implementation details about OAuth 2.0 Authorization Code flow, which can be valuable in many other situations.
Overview
The ODC Identity Bridge application consists of three modules:
OpenIDBridge - This web module provides a sample Login (Authorize) screen with only a username and password.
The direct URL of the Authorize screen is the URL returned by the ODC GetExternalLoginURL client action. The user is redirected to this URL to authenticate.
OpenIDBridgeAPI - This service module is a core implementation of an OpenID Connect/OAuth 2.0 compatible Identity Provider. The module exposes REST operations for ODC to discover endpoints, like the Authorize endpoint and exchange tokens.
OpenIDBridgeUtility - This code module provides only a single action, UrlDecode. You likely already have a similar utility action in your environment and may want to replace it.
Prerequisites
Before we dive further into the details, let's set up the necessary configurations to get ODC Identity Bridge up and running.
Install ODC Identity Bridge from Forge.
In O11 Service Center, we need to configure some Site Properties of the OpenIDBridgeAPI module.
In the ODC Portal, we need to add an Identity Provider configuration.
Open the OpenIDBridgeAPI module in Service Center and click on the Site Properties tab. First, set a value for ClientId and ClientSecret. You can think of them as a service account's username and password that ODC uses to identify itself to the OpenID Bridge Identity Provider.
ClientId - This can be any text string, such as "odc-dev-env" or just a UUID.
ClientSecret - Enter a strong password here.
Leave the Site Properties tab open as we need to revisit it shortly. Open another tab and browse to your ODC Portal and click on Manage - Identity providers.
Click Add provider - OpenID Connect.
Provider name - Choose a name for this identity provider, like OutSystems 11 Development.
Discovery endpoint - Use the URL: https://<Your O11 environment domain name>/OpenIDBridgeAPI/rest/Oauth/Discovery. After clicking on Get Details, the additional configuration details will appear on the right.
Client ID - Enter the Client ID you set in the Site Properties of the OpenIDBridgeAPI module in Service Center.
Client secret (secret value) - Enter the Client secret you set in the Site Properties of the OpenIDBridgeAPI module in Service Center.
PKCE - Select None.
Organization user email verification - Select Trust all user emails as verified.
Under Claim mapping:
- Username - Set to preferred_username.
Leave all other settings as they are and click Save.
Next, click on Assign and link this Identity Provider configuration to applications in your development stage.
💡
You will need a separate Identity Provider configuration for each of your stages.
Finally, click on the Redirect URLs tab and expand Apps in Development. Copy the value of the Login URL.
In the O11 Service Center, go to the Site Properties of the OpenIDBridgeAPI module and paste the Login URL value into the RedirectUri property.
Authentication Flow
With ODC Identity Bridge installed and configured lets look on how the overall authentication flow works.
An unauthenticated user tries to access an ODC application.
A SecurityException is thrown and handled in Common - OnException.
Your handler executes the GetExternalLoginURL client action to obtain the Authorize endpoint URL of the ODC Identity Bridge application in OutSystems 11.
Your handler redirects the user to this URL to sign in with O11 user credentials.
After signing in, the ODC Identity Bridge first redirects the user back to the RedirectURI of the ODC Identity Broker. This redirect includes an Authorization Code (code).
The ODC Identity Broker uses this code to request an identity and access token from the Token endpoint of the ODC Identity Bridge application.
It then decodes the Identity token, finds a user account or creates a new one, and authenticates the user.
Finally, it redirects the user back to the application they requested.
You already know that having a user account in ODC doesn't automatically grant access to an application. The user needs additional role assignments. There are several ways to ensure a user has roles assigned when signing in to ODC.
Pre-provision all user accounts from O11 to ODC using a Timer that creates or updates user accounts in ODC and assigns roles.
Use ODC Group Mappings to apply application roles based on attributes of a user's Identity Token.
💡
I recommend using Group Mappings instead of a sync. Timed synchronizations often cause delays that could lead to issues, while group mappings are (more) immediate. The ODC Identity Bridge components make it easy to add any number of additional attributes to the Identity Token for automatic role assignment. Please read my article
OutSystems Developer Cloud End-User Roles, Groups and Group Mappings for details on how to configure Group Mappings.
Please refer to the OutSystems Documentation Managing authorization and authentication for end-users - ODC Documentation for detailed instructions on adding external identity provider sign-in to applications.
ODC Identity Bridge
Let us look at some of the implementation details of the ODC Identity Bridge application. In Service Studio open the OpenIDBridgeAPI module.
Service Actions
ODC Identity Bridge exposes two service actions that are used in the sample Authorize screen in the OpenIDBridge web module.
Bridge_ValidateAuthorizationRequest
Validates the parameters that are sent by the ODC Identity Broker when redirecting a user to the Authorize endpoint (your Login screen in OutSystems 11). This action returns validation errors that are useful to troubleshoot the integration.
Bridge_AuthorizeUser
This service action is executed after a user submits its credentials in the Authorize screen of the OpenIDBridge web module.
User_Login - Performs a username/password login using the User_Login action of the OutSystems 11 user provider.
AuthCode - Generates a random authorization code.
AuthorizationRequest_Create - Saves the authorization code along with the user identifier and additional authentication request details to the database.
CallbackUri - Constructs the URL to which the browser must be redirected. This URL request includes the authorization code.
Discovery Endpoint
In Logic - Integrations - REST - Oauth inspect the exposed Discovery operation. This endpoint serves an OpenID Connect Discovery Document that looks like this
{
"issuer": "https://<your environment>",
"authorization_endpoint": "https://<your environment>/OpenIDBridge/Authorize",
"token_endpoint": "https://<your environment>/OpenIDBridgeAPI/rest/Oauth/Token",
"token_endpoint_auth_methods_supported": [
"client_secret_post"
],
"jwks_uri": "https://<your environment>/OpenIDBridgeAPI/rest/Oauth/Keys",
.... more options
}
The action flow simply builds the values for the discovery document. The important ones are:
authorization_endpoint - This is the full URL to your OutSystems 11 Login Page. This value must be changed if you roll your own Login screen.
token_endpoint - This endpoint is used by the ODC Identity Broker to exchange an authorization code for ID and access tokens.
jwks_uri - This endpoint provides the public key used by the ODC Identity Bridge to sign both ID and access tokens.
💡
The Discovery document informs ODC where to locate the individual endpoints. The discovery URL is the first thing you configure when adding a new Identity Provider in ODC Studio.
Token Endpoint
Next, examine the Token operation. This endpoint is used by the ODC Identity Broker to exchange an authorization code for ID and access tokens. After the user successfully signs in, the authorization code is sent to the RedirectURI of the configured Identity Provider in ODC Studio as part of the query string.
ParseCodeExchangeForm - The Token endpoint uses a URL-encoded form, and this action converts the form content into a structured format.
GetAuthorizationRequestByCode - Retrieves the authentication details saved during user login (Bridge_AuthorizeUser)
CreateIdentityToken - Creates and signs a JWT Identity Token using the popular JWT component.
CreateAccessToken - Even though ODC only uses the Identity token to authenticate a user, an access token must always be returned. This action creates and signs a JWT Access Token.
Keys
This operation serves the public key that matches the private key used to sign tokens from Data - Resources - Keys and returns it. See Roll Your Own Keys for details on how to exchange the signing key.
Adding Additional Claims
To use ODC's Group Mapping, you can add extra key-value pairs (claims) to the Identity Token. Modify the CreateIdentityToken and add additional claims to the LocalClaims local variable.
Roll Your Own Keys
ODC Identity Bridge has already included a public/private key pair to sign identity and access tokens, but you should replace the default with your own keys as soon as possible.
Run the following commands create a private and public key in PEM format.
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem
Next, you need to convert the public key (public.pem) to a JSON Web Key (JWK). The simplest way is to use an online converter like https://pem2jwk.vercel.app/ and save the JSON result to a file named public.jwk.
You can use any converter, but ensure that the resulting JSON document follows this structure:
{
"keys": [
{
"kty": "RSA",
"n": "<n>",
"e": "AQAB",
"ext": true,
"kid": "o11public",
"alg": "RS256",
"use": "sig"
}
]
}
💡
Important: Make sure to set the key name to o11public.
Finally, in Data - Resources - Keys, replace private.pem with your custom private key and the JWK conversion result with public.jwk.
Summary
By following this tutorial, you have successfully set up a working identity bridge between OutSystems 11 and OutSystems Developer Cloud.
You installed and configured ODC Identity Bridge in your O11 environment that exposes an OpenID Connect / OAuth 2.0 Identity Provider, and registered it in the ODC Portal. As a result, users from your existing OutSystems 11 user base can now sign in to ODC applications using their O11 credentials.
Thank you for reading. I hope you enjoyed it and that I've explained the important parts clearly. If not, please let me know 😊 Your feedback is greatly appreciated.
Follow me on LinkedIn to receive notifications whenever I publish something new.
