Our .NET MAUI mobile apps now support external authentication using AWS Cognito, allowing customers to use their existing identity provider (IdP) for login and user verification.

This enables seamless single sign-on (SSO), modern security standards, and centralized user management, without the customer needing to manage passwords inside our system.

We have already implemented this workflow internally (previously with Azure AD), and the system is built to support nearly any common enterprise identity solution.

• Allows our app to authenticate users through AWS Cognito, not local passwords.

• Cognito federates user identity from the customer’s preferred identity provider.

• Users authenticate via secure OAuth2/OIDC or SAML flows.

• After authentication, Cognito issues a JSON Web Token (JWT) which our API validates.

• This JWT is already fully supported by our Laravel backend and .NET MAUI app.

• Use existing logins (Azure AD, Google Workspace, Okta, ADFS, etc.)

• Eliminates separate passwords for the app.

• Centrally manage staff access using customer’s existing groups and policies.

• Enterprise-grade security using OAuth2, OIDC, and/or SAML.

• Reduced IT overhead for onboarding/offboarding staff.

AWS Cognito supports a very wide range of external IdPs.
Below are the main categories we support out-of-the-box.

Most modern identity systems support OIDC, which is the easiest and preferred method.

Examples:

• Azure Active Directory / Entra ID

• Okta

• Auth0

• Google Identity Platform

• Ping Identity

• Keycloak

• JumpCloud

Open

AWS Docs:
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html

For customers using older or on-prem solutions.

Examples:

• Microsoft ADFS

• Azure AD (SAML option)

• Okta (SAML)

• PingFederate

• Shibboleth

• OneLogin

• IBM Security Verify

Open

AWS Docs:
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html

(Usually for public-facing apps, but technically supported.)

Examples:

• Google

• Apple

• Facebook

• Amazon

AWS Docs:
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-social-idp.html

1. Customer provides details of their identity provider:

   • Client ID

   • Client Secret (if applicable)

   • Issuer URL

   • Redirect URLs

   • Optional: Group/role mappings

2. We configure their IdP inside AWS Cognito User Pool.

3. Our MAUI app redirects users to Cognito's hosted login page or native SSO flow.

4. The user logs in using the customer’s existing login system.

5. Cognito returns a JWT access token.

6. Our API validates the JWT and completes the login via our existing Laravel logic.

• All authentication is handled via secure industry standards:

  • OAuth 2.0

  • OpenID Connect (OIDC)

  • SAML 2.0

• Passwords never go through our servers.

• MFA / password rules / user lifecycle management remain fully controlled by the customer.

• JWT tokens use Cognito’s public keys (JWK) for strict signature validation.

For any external IdP setup, customers must supply:

• Identity provider type (OIDC or SAML)

• Metadata URL or discovery document

• Test login credentials (temporary or dedicated test account)

• Any preferred group-to-role mapping (optional)

• Whether they want MFA enforced through their IdP

We handle the rest.

Almost all common enterprise systems, as long as they support OIDC or SAML, which most do.

No, authentication happens entirely through the customer’s IdP and AWS Cognito.

No, they log in with their existing company credentials.

Yes, password policies, MFA, device restrictions, and user management are all inherited from the customer’s identity provider.