OAuth2 Server (Identity Provider)

Overview#

An organisation has deployed Argus as their primary intelligence platform and now wants their case management system, their document repository, and a custom analyst tool to all authenticate users through Argus rather than maintaining three separate credential stores. The OAuth2 Server module turns Argus into an Identity Provider: any application that can implement OAuth 2.0 can accept "Sign in with Argus" and get scoped access to exactly the user data and permissions it needs, nothing more.

Internal microservices, partner integrations, and native mobile applications can all register as clients and participate in the same authentication ecosystem. The platform handles token issuance, refresh, revocation, and the complete PKCE flow for public clients, so the connected applications do not need to build any of that themselves.

Open Standards#

OAuth 2.0 (RFC 6749): The core authorisation framework implemented by this module; the platform acts as an authorisation server issuing authorisation codes, access tokens, and refresh tokens to registered clients using the authorisation code grant.
Proof Key for Code Exchange (PKCE, RFC 7636): Enforced for public clients (mobile apps and single-page applications); the server validates the code_challenge (S256 method) at authorisation and the matching code_verifier at token exchange to prevent authorisation-code interception.
JSON Web Token (JWT, RFC 7519): Access tokens and refresh tokens are issued as signed JWTs; the platform publishes its public signing keys via a JWKS endpoint (RFC 8615 /.well-known/jwks.json) so resource servers can verify tokens independently.
OAuth 2.0 Bearer Token Usage (RFC 6750): Resource servers accept issued tokens as Authorization: Bearer credentials; the platform enforces scope, expiry, and revocation checks when tokens are presented to protected APIs.
OpenID Connect Core 1.0: The authorisation server exposes the openid, profile, and email scopes and is registered as an OpenID Connect Provider, allowing clients to request identity claims alongside authorisation.
SAML 2.0 (OASIS): Organisations with an existing SAML identity provider can federate into the platform; the module interoperates with SAML 2.0 IdPs alongside its own OAuth2 server role, supporting mixed-IdP environments with Keycloak and Zitadel.
Well-Known URI (RFC 8615): Discovery metadata, including the JWKS document, is served under the standardised /.well-known/ URI scheme so that clients and resource servers can locate endpoints and keys without out-of-band configuration.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Key Features#

Authorization Code Flow: Standard OAuth 2.0 flow where users authenticate through the platform and receive a short-lived authorization code exchanged for access tokens
PKCE Support: Enhanced security for mobile applications and single-page applications that prevents authorization code interception attacks without requiring a client secret
Client Registration: Register third-party applications as confidential (server-side) or public (mobile/SPA) clients with pre-registered redirect URIs
Scope-Based Authorization: Granular permission control including OpenID Connect, profile, email, roles, and resource-level read/write scopes
Token Lifecycle Management: Short-lived access tokens for API access, long-lived refresh tokens for session continuity, and support for immediate token revocation
Redirect URI Validation: All redirect URIs must be pre-registered during client registration to prevent open redirect attacks
CSRF Protection: State parameter support to prevent cross-site request forgery during the authorization flow
Secure Secret Storage: Client secrets are cryptographically hashed and shown only once during registration
Multi-Client Support: Users can register and manage multiple OAuth clients through a self-service interface

Use Cases#

A partner application implements "Sign in with Argus" so users authenticate with their existing platform credentials, gaining scoped access to only the data the application requires
Internal microservices register as confidential clients to access platform APIs on behalf of users, providing unified authentication across the service architecture with a complete audit trail
A native mobile application uses PKCE-enhanced authorization code flow to securely authenticate users without exposing client secrets, storing tokens in the device's secure enclave
Organisations integrate external tools by registering OAuth clients, enabling single sign-on and centralised user management across their technology stack

Integration#

The OAuth2 Server connects with the core authentication and authorisation system for user identity verification, the JWT token management system for token generation and validation, and works alongside enterprise SSO solutions including SAML 2.0 federation, Zitadel IAM, and Keycloak for organisations with mixed identity provider requirements.