iASSET & Cursor: OAuth2 gateway and gRPC microservices
Throughline: an API Gateway that centralizes OAuth2 authentication (token validation, scopes) and routes to gRPC services behind the public perimeter. This use case describes the same iASSET method as the Gemini CLI guide, replacing local work with Cursor (rules, Agent, spec/proto context).
Method: iASSET rules and skills upstream; during development, handle the spec in Cursor; commit and push; in CI, verify spec + security on the diff (OAuth2, TLS, scopes), then tests and MR; finally a human review.
Cursor is not an authorization server: it helps produce and review code and contracts; the OAuth2 issuer remains a dedicated service.
Diagram — iASSET method (OAuth2 gateway + gRPC)
Same sequence as the Gemini guide: upstream → dev → Git → CI → human. Here development relies on Cursor and the scope is the auth gateway and gRPC services.
Step-by-step (gateway case)
Cursor rules and the spec frame changes around JWT validation, exposed routes, and gRPC calls. In CI, checks remain on the repository text (spec, proto, gateway).
Upstream — iASSET + Cursor
Rules/commands in the repo: gateway spec, proto, forbidden areas (no plaintext secrets, documented scopes).
Spec — auth & surface
AC: who authenticates, which OAuth2 flows, which public vs internal gRPC endpoints.
Implementation
Gateway (JWT validation, routing), gRPC services, versioned `.proto` contracts.
Commit
Clear messages and scope; no keys or tokens in the diff.
Push
Pipeline on branch / MR.
CI — spec + security
Diff reviewed against auth spec (scopes, issuer, gateway paths).
CI — tests & MR
As in the diagram; then human validation.
Recommended CI order
Lint + typecheck → spec + security (OAuth2, scopes, sensitive paths) → tests → MR → human review.
Cursor for each iASSET pillar (examples)
No single 'analyze' command: you combine rules, spec, and file context (proto, OpenAPI) in Cursor — like Gemini CLI skills.
| Pillar | Cursor lever (example) | Note |
|---|---|---|
| [A] | Rules + repo structure | Forbid changes outside `gateway/`, `proto/` per policy; prompts in `.cursor/rules`. |
| [S] spec | Composer / Agent with spec | Import `docs/spec-oauth-gateway.md` and proto files to frame changes. |
| [S] sec | Checklists in rules | No secrets in code; JWKS, scopes, mTLS reminders. |
| [E] | Review before push | Diff reviewed with iASSET context; same logic can be automated in CI with scripts. |
| [T] | Test/mocks generation | Help mocking issuer, gRPC test clients — assertions remain in the repo. |
The five iASSET pillars (gateway case)
[A] Architecture
Clear boundary: edge (REST/OpenAPI), authentication gateway and routing, internal services in gRPC. Cursor helps enforce folders (`gateway/`, `proto/`, `services/`) via rules — the domain 'who can do what' remains explicit in the spec.
[S] Specification
AC on OAuth2 flows (client credentials, code + PKCE…), list of scopes, mapping to gRPC methods. `.proto` and edge OpenAPI are sources of truth for review.
[S] Security
TLS, JWT validation (issuer, audience, exp), least privilege on scopes. CI checks the diff against these rules — no cluster execution in the job.
[E] Evaluation
MR review with spec + diff context; hooks or scripts before merge. Cursor (Agent/rules) accelerates proto ↔ gateway consistency, human review decides business trade-offs.
[T] Testing
Automated tests required on auth paths and gRPC errors; load/chaos optional depending on criticality.
Target breakdown
From client to gateway to gRPC
Les apps appellent la gateway en HTTPS ; celle-ci valide les jetons OAuth2 et appelle les services gRPC sur le réseau interne.
Clients
Web, mobile, partenaires (Bearer / cookies selon spec)
API Gateway
TLS, OAuth2, scopes, routage
Services gRPC
protobuf, mTLS ou réseau privé
Clients
HTTPS vers la gateway
Gateway
Validation JWT, scopes
gRPC
Services métier
Règle iASSET — séparation auth / métier
La gateway concentre la politique d'accès (tokens, scopes) ; les services gRPC implémentent le métier et font confiance à l'identité déjà validée (claims propagés), selon votre modèle de confiance.
[S]pécification & contrats
Exemples — claims & appel gRPC
Côté gateway, vous projetez les claims OAuth2 vers un contexte métier ; côté service, vous restez sur le contrat protobuf. Adaptez les langages à votre stack.
// Ex. gateway/middleware/auth-context.ts
export interface AuthContext {
sub: string;
scopes: string[];
issuer: string;
}
// Après validation JWKS (issuer, exp, aud)
export function requireScope(ctx: AuthContext, s: string) {
if (!ctx.scopes.includes(s)) throw new Error('insufficient_scope');
}
// Extrait proto — contrat interne (simplifié)
syntax = "proto3";
package identity.v1;
service SessionReader {
rpc GetSubject(GetSubjectRequest) returns (GetSubjectResponse);
}
En CI, vérifiez que les changements de scopes et de proto restent alignés avec la spec — via scripts et revue assistée (Cursor en local, pipeline sur le diff).
[E]valuation & [T]esting — CI pipeline
GitLab CI: job order (adapted)
Same logic as the iASSET + Gemini guide: code quality first, then spec/security compliance on the diff, then tests, then MR. Replace 'Gemini' calls with your scripts (proto lint, spec checks, internal policy).
MR: the description can link the OAuth2 spec, modified .proto files, and gate results.
# Gateway + gRPC : pas de secret en clair dans le diff
lint: ...
asset_spec_security:
needs: [lint]
script:
- node scripts/check-asset-spec.js --spec docs/spec-oauth-gateway.md
grpc_tests:
needs: [asset_spec_security]
script: buf test && npm run test:integration
check-asset-spec.js is an example: it fails if the diff contradicts the scopes matrix or sensitive paths defined in the spec.
Merge definition (checklist)
Objective criteria for an authentication gateway and gRPC services.
- Versioned OAuth2/OIDC spec and scopes ↔ endpoints matrix.
- Green lint and typecheck; compatible protos (breaking changes identified).
- No secrets or private certs in the repo; JWKS/issuer documented.
- Auth integration tests and gRPC contract tests green on the scope.
- Human review: exposed surface and delegation to the authorization server.