Hi,
I'm currently setting up end-user authentication and M365 authorization for our O11 env using Microsoft Entra ID, and I'd appreciate some guidance or advice from the community, especially the ones who had already implemented this.
Our requirements:
-All users authenticated via Entra SSO
-Some users and apps will require access tokens to external resources, depending on the defined scopes
I've narrowed it down to two appraoches:
1. Built-in MS Entra Auth (OOTB): https://success.outsystems.com/documentation/11/user_management/end_users_authentication/configure_microsoft_entra_authentication/
The environment-wide end-user authentication configuration from service center. This is easy to set up, leverages SAML (apparently), so it does not provide OAuth 2.0 access and refresh tokens that we need for the API calls.
2. The OIDC Client Forge Component:
https://www.outsystems.com/forge/component-overview/13850/oidc-client-o11
This forge component will have to be modified a bit for our needs, it's more complex to maintain, but it provides the full OIDC flow (authentication and authorization).
That said, a few questions:
1. For those who have implemented either approach, what has your experience been?
2. Are there any significant downsides/added complexities to going fully with the OIDC Client?
3. Has anyone run a hybrid setup (keeping the OOTB Entra authentication as the default for SSO and using the OIDC Client authorization flow exclusively for apps that require API access tokens) provide any added value or would it just increase the complexity unnecessarily, as there will be 2 Authentication flows?
I am more inclined towards the standalone OIDC Client approach, as it covers both the authentication and authorization in one single flow and gives us the flexibility to request Graph API scopes only for users/apps that actually need them. But we will have to develop the user-import from Entra and the user-mapping separately, as I can see.
Any insights or lessons learned would be highly appreciated, thanks in advance :)
From my experience, going fully custom OIDC does not necessarily add that much complexity, and it gives you significantly more flexibility around scopes, tokens, and authorization flows.
For context, I’ve worked with SAML, hybrid (Okta), and full OIDC (Entra) authentication models.
The key question is whether your API access really requires delegated user tokens.
If it does, then full OIDC is probably the better fit.
If it does not, you can keep the OOTB authentication for end-user SSO and use Entra app registrations/service principals with client credentials for integrations. This gives you the API integration capabilities while keeping the built-in simplicity for user authentication.
The main trade-off with a full OIDC approach is the additional effort required to manage identity, roles, and authorization ownership between Entra and OutSystems.
I would also be careful with custom scopes. I’d keep them minimal and use them mainly as governance guardrails, while keeping the authorization model owned by OutSystems. Otherwise, you risk creating a dependency on Entra that can become increasingly complex to manage as applications, roles, and permissions evolve.