Skip to content

feat: add M2M application schema and storage layer#529

Closed
lakhansamani wants to merge 1 commit into
mainfrom
feat/m2m-application-schema-storage
Closed

feat: add M2M application schema and storage layer#529
lakhansamani wants to merge 1 commit into
mainfrom
feat/m2m-application-schema-storage

Conversation

@lakhansamani

Copy link
Copy Markdown
Contributor

Summary

  • Adds Application schema for machine-to-machine (M2M) service accounts with fields: name, client_id, client_secret, scopes, roles, is_active, created_by
  • Implements full CRUD: CreateApplication, GetApplicationByID, GetApplicationByClientID, ListApplications, UpdateApplication, DeleteApplication
  • Supports all 6 DB providers (SQL/GORM, MongoDB, ArangoDB, Cassandra, DynamoDB, Couchbase)
  • Creates table/collection with unique indexes on name and client_id
  • Includes integration tests for the full CRUD lifecycle

Related

Ref: RFC #509

Test plan

  • Run go build ./... — compiles clean
  • Run integration tests: go test -p 1 -v -run TestApplications ./internal/integration_tests/
  • Verify schema migration creates applications table with correct indexes

🤖 Generated with Claude Code

Implements RFC #509: machine-to-machine (M2M) application schema and
full CRUD storage layer across all 6 database providers (SQL/GORM,
MongoDB, ArangoDB, Cassandra/ScyllaDB, DynamoDB, Couchbase).

- Add Application schema with client_id/client_secret, scopes, roles,
  is_active, created_by, and standard timestamp fields
- Add Application collection to CollectionList with authorizer_applications
- Extend storage.Provider interface with CreateApplication,
  GetApplicationByID, GetApplicationByClientID, ListApplications,
  UpdateApplication, and DeleteApplication methods
- Implement all 6 DB provider methods following existing webhook patterns
- Add unique indexes on name and client_id for each provider
- Add integration test suite covering full CRUD lifecycle
@lakhansamani

Copy link
Copy Markdown
Contributor Author

Thanks for this, and apologies it sat open while the codebase moved.

This is now superseded by the client registry that shipped as part of the machine-agent-identity program. The Client schema (internal/storage/schemas/client.go) with Kind: "service_account" covers exactly what this Application schema introduced — client_id/client_secret, name/description, scopes (allowed_scopes), is_active, timestamps — and is a superset (adds grant_types, redirect_uris, token_endpoint_auth_method, org_id, and the interactive-vs-service_account kind).

Crucially, the M2M functionality this was a foundation for is already fully wired on main: the client_credentials grant at /oauth/token, client assertions / trusted issuers (private_key_jwt, SPIFFE, K8s TokenReview), RFC 8693 delegation, and service accounts as FGA subjects — all built on Client. Adding a parallel Application table would create two competing M2M models.

Closing as superseded. The only field here not on Client is created_by (creator provenance); that's already captured in the audit log on client creation, and if wanted it's a one-field add to Client rather than a separate schema. Really appreciate the contribution — the direction was right, it just landed via the registry work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant