iASSET & Cursor : gateway OAuth2 et microservices gRPC
Fil rouge : une API Gateway qui centralise l'authentification OAuth2 (validation des jetons, scopes) et route vers des services en gRPC derrière le périmètre public. Ce cas d'usage décrit la même méthode iASSET que le guide Gemini CLI, en remplaçant le travail local par Cursor (rules, Agent, contexte spec/proto).
Méthode : règles et skills iASSET en amont ; au dev, traiter la spec dans Cursor ; commit et push ; en CI, vérifier spec + sécurité sur le diff (OAuth2, TLS, scopes) puis tests et MR ; enfin l'humain.
Cursor n'est pas un serveur d'autorisation : il aide à produire et revoir le code et les contrats ; l'issuer OAuth2 reste un service dédié.
Schéma — méthode iASSET (gateway OAuth2 + gRPC)
Même enchaînement que le guide Gemini : amont → dev → Git → CI → humain. Ici le développement s'appuie sur Cursor et le périmètre est la gateway d'auth et les services gRPC.
Détail des étapes (cas gateway)
Les rules Cursor et la spec cadreront les changements sur la validation JWT, les routes exposées et les appels gRPC. En CI, les contrôles restent sur le texte du dépôt (spec, proto, gateway).
Amont — iASSET + Cursor
Rules / commands dans le dépôt : spec gateway, proto, interdits (pas de secret en clair, scopes documentés).
Spec — auth & surface
CA : qui s’authentifie, quels flux OAuth2, quels endpoints publics vs internes gRPC.
Implémentation
Gateway (validation JWT, routage), services gRPC, contrats `.proto` versionnés.
Commit
Messages et périmètre clairs ; pas de clé ou token dans le diff.
Push
Pipeline sur la branche / MR.
CI — spec + sécu
Diff relu contre la spec auth (scopes, issuer, chemins gateway).
CI — tests & MR
Comme sur le schéma ; puis validation humaine.
Ordre recommandé en CI
Lint + typecheck → spec + sécu (OAuth2, scopes, chemins sensibles) → tests → MR → revue humaine.
Cursor pour chaque pilier iASSET (exemples)
Pas de commande unique « analyze » : vous combinez rules, spec et contexte fichiers (proto, OpenAPI) dans Cursor — comme les skills côté Gemini CLI.
| Pilier | Levier Cursor (exemple) | Note |
|---|---|---|
| [A] | Rules + structure repo | Interdire les modifications hors `gateway/`, `proto/` selon policy ; prompts dans `.cursor/rules`. |
| [S] spec | Composer / Agent avec spec | Importer `docs/spec-oauth-gateway.md` et fichiers proto pour cadrer les changements. |
| [S] sécu | Checklists dans rules | Pas de secret dans le code ; rappels JWKS, scopes, mTLS. |
| [E] | Revue avant push | Diff relu avec le contexte iASSET ; même logique peut s’automatiser en CI avec des scripts. |
| [T] | Génération de tests / mocks | Aide à mocks issuer, clients gRPC de test — les assertions restent dans le repo. |
Les cinq piliers iASSET (cas gateway)
[A] Architecture
Frontière claire : edge (REST/OpenAPI), gateway d’authentification et routage, services internes en gRPC. Cursor aide à respecter les dossiers (`gateway/`, `proto/`, `services/`) via rules — le domaine « qui peut quoi » reste explicite dans la spec.
[S] Spécification
CA sur les flux OAuth2 (client credentials, code + PKCE…), liste des scopes, mapping vers méthodes gRPC. Les `.proto` et OpenAPI edge sont les sources de vérité pour la revue.
[S] Sécurité
TLS, validation JWT (issuer, audience, exp), moindre privilège sur les scopes. La CI vérifie le diff contre ces règles — pas d’exécution du cluster dans le job.
[E] Evaluation
Revue de MR avec contexte spec + diff ; hooks ou scripts avant merge. Cursor (Agent / rules) accélère la cohérence proto ↔ gateway, la revue humaine tranche le métier.
[T] Test
Tests automatisés obligatoires sur les chemins d’auth et les erreurs gRPC ; charge / chaos optionnels selon criticité.
Découpage cible
Du client à la gateway puis au 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]est — pipeline CI
GitLab CI : ordre des jobs (adapté)
Même logique que le guide iASSET + Gemini : qualité du code puis conformité spec/sécu sur le diff, puis tests, puis MR. Remplacez les appels « Gemini » par vos scripts (lint proto, check spec, policy maison).
MR : la description peut lier la spec OAuth2, les fichiers .proto modifiés et les résultats des gates.
# 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 est un exemple : il échoue si le diff contredit la matrice des scopes ou les chemins sensibles définis dans la spec.
Définition de merge (checklist)
Critères objectifs pour une gateway d'authentification et des services gRPC.
- Spec OAuth2 / OIDC et matrice scopes ↔ endpoints versionnées.
- Lint et typecheck verts ; proto compatibles (breaking changes identifiés).
- Pas de secrets ou certificats privés dans le dépôt ; JWKS / issuer documentés.
- Tests d’intégration auth et contrats gRPC verts sur le périmètre.
- Revue humaine : surface exposée et délégation au serveur d’autorisation.