AuthGuard Request a demo

Single sign-on for applications

Confirm once. Open the right apps, not all of them.

AuthGuard is the identity provider for your applications: internal portals through OpenID Connect, cloud services through SAML 2.0 and Microsoft 365 through federation. People confirm once, and the access policy decides, application by application, who gets in.

  • OpenID Connect
  • SAML 2.0
  • Microsoft 365
  • Deny by default
Single sign-on · ana@example.comillustrative example
Passkey confirmedsingle sign-on for up to 8 h
  • HR PortalOIDCContinue as ana@example.com
  • Google WorkspaceSAML 2.0Signed response sent by HTTP-POST
  • Microsoft 365Federationm365.example.com is federated
  • PaymentssensitiveAlways asks for a fresh passkey
  1. Passkey
  2. HR Portal
  3. Microsoft 365
  4. Fresh passkey

Watch

One passkey, the right applications.

Narrated in English, with English and Portuguese subtitles. Real product screens; people, organisations and amounts are fictitious.

How it works

Three protocols, one policy.

Every application is registered in the console and only accepts sign-ins that an access policy rule allows. Without a rule, the answer is no.

  1. 01 · OpenID Connect

    Modern applications

    Authorisation code with PKCE S256, RS256 or ES256 ID tokens, confidential and public clients, rotating refresh tokens and application-initiated logout.

  2. 02 · SAML 2.0

    Cloud services

    Signed responses over HTTP-POST, metadata import, and templates for Google Workspace, AWS IAM Identity Center, Salesforce, Slack and Atlassian.

  3. 03 · Microsoft 365

    Domain federation

    People in a custom Entra ID domain sign in to Microsoft 365 with AuthGuard’s passkey, phone approval or single sign-on. Entra remains the directory.

  4. 04 · Policy

    One rule per application

    Every sign-in is evaluated for the federation.authorize action. Sensitive applications, such as cloud consoles or payments, always ask for a fresh passkey.

Illustrative example

Monday, 9:00: three applications, one confirmation.

Ana opens the HR portal and is sent to AuthGuard. She confirms with her passkey and lands back in the portal. When she opens Microsoft 365, the page offers to continue with the same account, with no new confirmation.

When she opens the payments application, which is marked sensitive, AuthGuard asks for her passkey again, even though single sign-on is active. If she steps away, the session ends after the inactivity period her organisation set.

By protocol

Connect what you already use.

OpenID Connect

For your own applications

  • Published discovery document and JWKS
  • PKCE required for public clients
  • Client authentication with a secret or private_key_jwt
  • Token revocation (RFC 7009)
SAML 2.0

For cloud services

  • Entity ID, metadata URL and certificate in the console
  • NameID by email, per-application random identifier, UUID or directory name
  • Sign the response, the assertion or both
  • Up to 32 attributes per application
Microsoft 365

For your organisation’s domain

  • A PowerShell 7 setup script generated by the console
  • Anchors that link each person to their Microsoft account
  • Privileged roles stay on *.onmicrosoft.com accounts
  • A documented command to return to managed sign-in

Worth knowing

  • SAML: no Single Logout, no encrypted assertions and no Artifact binding.
  • OpenID Connect: logout is initiated by the application; there is no front-channel logout.
  • Microsoft 365: no WS-Trust, which rules out legacy clients and Windows sign-in on Entra-joined devices for federated people.
  • AuthGuard does not create accounts in your applications: each person must already exist there.
  • Signing out of AuthGuard does not end sessions the applications have already created.

In the help centre

Pilot

Start with two applications.

One internal application through OpenID Connect, and one cloud service through SAML or Microsoft 365. We review the policy rules and sensitive applications with you.

geral@authguard.pt