Client Credentials Grant Type

Feature requests
1

Hello Uitsmijter Community!

I’d like to propose adding support for the Client Credentials Grant Type (RFC 6749, Section 4.4) to Uitsmijter. This addition would unlock powerful machine-to-machine (M2M) authentication scenarios.

Why Client Credentials Matter

Currently, Uitsmijter excellently handles user-centric authentication flows (authorization_code, refresh_token, and password grants). However, there’s a growing need for services to authenticate directly without user interaction. The client_credentials grant enables exactly this.

Real-World Use Cases

1. Microservices Authentication

In microservice architectures, services need to communicate securely without user context:

  • Order Service needs to check inventory with Stock Service

  • Notification Service needs to fetch user preferences from User Service

  • Analytics Service needs to aggregate data from multiple microservices

With client_credentials, each service gets its own identity and can authenticate independently using its client_id and client_secret.

2. IoT Device Integration

IoT devices and embedded systems need API access without user interaction:

  • Smart sensors pushing telemetry data

  • Industrial equipment reporting status

  • Connected vehicles synchronizing with backend services

  • Home automation systems accessing cloud services

These devices can securely authenticate using their pre-configured credentials, perfect for headless operation.

3. Background Jobs & Automation

Scheduled tasks and batch processes require reliable API access:

  • Nightly data synchronization jobs

  • Automated report generation

  • Backup and maintenance scripts

  • CI/CD pipeline deployments

  • Monitoring and alerting systems

Client credentials provide a clean way to grant these automated processes the exact permissions they need.

Do you think this would fit to uitsmijter?

2

Hi Natalia,

Thanks for putting together such a thorough proposal. You’ve clearly laid out why client credentials matter, and I agree this would be a valuable addition to Uitsmijter. The use cases you describe—microservices communication, IoT devices, and background jobs—are exactly the scenarios where M2M authentication becomes essential.

I’d love to see this implemented. Here’s a rough outline of how we might approach it:

Implementation Roadmap

Core Token Endpoint Support

  • Extend TokenController to handle grant_type=client_credentials
  • Add a dedicated ClientCredentialsGrantHandler
  • Implement provider validation for M2M clients

Client CRD Extensions

  • Token lifetime configuration specific to M2M use cases
  • Scope restriction mechanisms to limit what each client can access

Observability

  • Prometheus metrics for M2M token issuance and usage
  • Audit logging enhancements to track machine-to-machine activity

Documentation

  • Clear examples for common scenarios (microservices, IoT, scheduled jobs)

One thing worth considering early: the provider protocol is already handling quite a few parameters. Adding client credentials support will put more pressure on that, so we’ll need to think carefully about how to structure this in a way that remains backward compatible. Perhaps a versioned approach or optional extension fields could work, but it’s worth discussing before we commit to an implementation path.

3

We update the credentials object in providers to support the grant_type infomation. This is backward compatible when we use new properties for client_id and client_secret later on.

We will beginn the work for the upcoming Version 0.11 :tada:

4

How to implement:
I think, that theHam application is the right target:

  • Has interceptor enabled (id.ham.test) and OAuth client (cd7a444a-…)
  • Has no existing e2e spec files — no risk of breaking anything
  • Has both interceptor-protected pages (page.ham.test) and an OAuth auth domain (id.ham.test)

In Deployment/e2e/applications/Ham/tenant.yaml

Update UserLoginProvider to check credentials.grant_type. Deny if it is interceptor:

  class UserLoginProvider {
    auth = false;
    constructor(credentials) {
      if (credentials.grant_type === 'interceptor') {
        commit(false);
        return;
      }
      this.auth = credentials.username.endsWith("@example.com");
      commit(true);
    }
    get canLogin() { return this.auth; }
    get userProfile() { return { name: "Test User" }; }
    get role() { return "user"; }
  }

UserValidationProvider is unchanged.

In: Tests/e2e/playwright/tests/GrantType/GrantTypeCheck.spec.ts

Two test.describe groups:

Happy path (authorization_code):

  • Use loginAuthorizeFormRequest directly against id.ham.test with Ham’s client ID
  • Submit valid credentials (username ending in @example.com)
  • The grant type will be authorization_code (OAuth flow)
  • Expect: HTTP 302 redirect with code= in the URL

Error path (interceptor):

  • Navigate the browser to https://page.ham.test/ — Traefik intercepts and redirects to the login page with mode=interceptor
  • Submit the same valid credentials (username ending in @example.com)
  • The grant type will be interceptor — the provider calls commit(false)
  • Expect: stays on id.ham.test/login, title is “Login”, WRONG_CREDENTIALS error visible

I think this is the right place to start. I will open a feature later today!