Application Identification Service

Establish trust before applications exchange information

Identify every calling application, control what it may request, and give shared services one trusted source for onboarding and token verification.

The business challenge

Why this capability belongs in a shared service

HTTPS protects transport but does not establish which application is calling, whether it is active, or what it may request.

Duplicating application lists and credentials across services makes trust inconsistent and difficult to revoke.

Architectural responsibility

One clear role within the Enterprise Platform

01

Register Business Applications and shared services

02

Maintain application identity and lifecycle status

03

Manage audiences and scopes

04

Issue signed JWT access tokens

05

Support token verification

06

Maintain registered URLs, certificates, and approved configuration

07

Activate, suspend, or deactivate applications centrally

High-level journey

How the responsibility flows

  1. 01

    Application onboarding

    Ownership, contacts, certificates, services, scopes, audiences, and approved URLs are registered.

  2. 02

    Credential establishment

    Approved credential material is delivered through a controlled process.

  3. 03

    Token request

    The application requests a token for a defined audience and scope.

  4. 04

    JWT issuance

    AIS validates status and authorization before issuing a short-lived signed token.

  5. 05

    Service validation

    The target service verifies signature, issuer, expiry, client, audience, and scope.

  6. 06

    Lifecycle control

    Central suspension or deactivation prevents new trusted activity.

Key capabilities

Designed for practical enterprise adoption

  • Central application onboarding
  • Unique application identity
  • Short-lived signed JWTs
  • Audience restriction
  • Scope-based authorization
  • Token verification
  • Lifecycle control
  • Registered URLs
  • Certificates and cryptographic configuration
  • Business and technical ownership

Security and governance

Trust at every boundary

  • Credentials never enter Angular or browser-delivered code
  • Tokens use minimum necessary audiences and scopes
  • Receiving services verify all relevant claims
  • Keys and credentials follow controlled rotation
  • Secrets and complete tokens are excluded from ordinary logs
  • Administrative changes are authorized and auditable

Business benefits

Value created through reuse and clear ownership

One source of application trust
Faster shared-service onboarding
Consistent authorization
Central deactivation
Reduced credential duplication
Clear ownership
Improved auditability

Flagship demonstration

See the service inside a connected platform journey

A new Business Application receives authorization for Notification Service. Its token succeeds for the approved notification scope but is rejected when used against Payment Service or an unauthorized operation.

View Demonstration Center

Start the conversation

Give every enterprise service a common language of trust

Protect shared services with centralized onboarding, signed access tokens, audiences, and scopes.