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)
Single sign-on for applications
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.
Watch
Narrated in English, with English and Portuguese subtitles. Real product screens; people, organisations and amounts are fictitious.
How it works
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.
Authorisation code with PKCE S256, RS256 or ES256 ID tokens, confidential and public clients, rotating refresh tokens and application-initiated logout.
Signed responses over HTTP-POST, metadata import, and templates for Google Workspace, AWS IAM Identity Center, Salesforce, Slack and Atlassian.
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.
Every sign-in is evaluated for the federation.authorize action. Sensitive applications, such as cloud consoles or payments, always ask for a fresh passkey.
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
Pilot
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