The Rarely Known Fact: Using Google Service Account for M2M JWT Authentication and Authorization

TL;DR

Google service accounts can handle machine-to-machine (M2M) authentication without an end user in the loop. This post shows how to generate and verify JSON Web Tokens (JWTs) with custom claims (for example, a role claim) in NestJS, using Google’s key management instead of rolling your own.

Related repos you can clone and run: service-b service-c

Table of Contents

• Overview of M2M Authentication with Google Service Accounts
• Setting Up the Google Service Account
• Generating a JWT in Service B
• Verifying the JWT in Service C
• Benefits and Conclusion
  • Performance and Security Benefits
  • Conclusion

Overview of M2M Authentication with Google Service Accounts

In a microservices architecture, services need to authenticate each other without a human present. Google service accounts solve this by issuing JWTs with standard and custom claims. The issuing service signs the token with a private key, and the receiving service verifies it against Google’s published public certificates. Neither side has to manage a shared secret.

Setting Up the Google Service Account

1. Create a service account.

   • Go to the Google Cloud Console.
   • Navigate to IAM & Admin > Service Accounts.
   • Create a new service account and download its JSON key file (for example, service-account-key.json).

2. Understand the key file.

   • private_key: signs the JWT.
   • client_email: becomes the issuer (iss) in the JWT payload.
   • private_key_id: goes in the JWT header (kid) so the verifier knows which public key to fetch.

Generating a JWT in Service B

Service B generates a JWT with a custom role claim, signed with the service account’s private key:

1
import * as jwt from 'jsonwebtoken';
2
import { ConfigService } from '@nestjs/config';
3
import { Injectable } from '@nestjs/common';
4

5
@Injectable()
6
export class AuthService {
7
  constructor(private configService: ConfigService) {}
8

9
  generateToken(role: string): string {
10
    const privateKey = this.configService.get<string>('private_key');
11
    const clientEmail = this.configService.get<string>('client_email');
12
    const privateKeyId = this.configService.get<string>('private_key_id');
13

14
    const payload = {
15
      iss: clientEmail,
16
      aud: 'http://localhost:3001', // Service C's endpoint
17
      iat: Math.floor(Date.now() / 1000),
18
      exp: Math.floor(Date.now() / 1000) + 3600, // 1 hour
19
      role, // custom claim for authorization
20
    };
21

22
    return jwt.sign(payload, privateKey, {
23
      algorithm: 'RS256',
24
      keyid: privateKeyId,
25
    });
26
  }
27
}

Key points:

• The payload combines standard claims (iss, aud, iat, exp) with a custom role claim.
• Signing uses RS256 with the service account’s private key. The kid header tells the verifier which public key to use, so key rotation does not break existing tokens.

Verifying the JWT in Service C

Service C fetches Google’s public certificates and verifies the token against them, then checks the custom claim. The 2025 version of this example used a raw https.get call with a manual JSON buffer. Since NestJS 12 requires Node 20+, the built-in fetch API is the simpler choice today:

1
import * as jwt from 'jsonwebtoken';
2
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
3

4
@Injectable()
5
export class AuthGuard implements CanActivate {
6
  private serviceAccountEmail = '[email protected]';
7

8
  async canActivate(context: ExecutionContext): Promise<boolean> {
9
    const request = context.switchToHttp().getRequest();
10
    const token = request.headers.authorization?.split(' ')[1];
11
    if (!token) return false;
12

13
    const certs = await this.getCerts();
14
    const decodedHeader = jwt.decode(token, { complete: true })?.header;
15
    const publicKey = certs[decodedHeader?.kid ?? ''];
16
    if (!publicKey) return false;
17

18
    const decoded = jwt.verify(token, publicKey, {
19
      algorithms: ['RS256'],
20
      audience: 'http://localhost:3001',
21
      issuer: this.serviceAccountEmail,
22
    }) as { role?: string };
23

24
    return decoded.role === 'admin'; // grant access only for the admin role
25
  }
26

27
  private async getCerts(): Promise<Record<string, string>> {
28
    const res = await fetch(
29
      `https://www.googleapis.com/service_accounts/v1/metadata/x509/${this.serviceAccountEmail}`,
30
    );
31
    if (!res.ok) {
32
      throw new Error(`Failed to fetch Google certs: ${res.status}`);
33
    }
34
    return res.json();
35
  }
36
}

Highlights:

• The public keys come straight from Google’s endpoint, no local cert file to maintain.
• Verification checks the signature, audience, and issuer in one call.
• Access is granted only when the decoded token’s role is admin.

Benefits and Conclusion

Performance and Security Benefits

• Efficiency: Google rotates keys and distributes certificates for you, so there’s no manual key management. Verification is fast once the certs are fetched.
• Security: The private key never leaves Service B. Verification against Google’s public certificates guarantees the token wasn’t tampered with.
• Scalability: Centralized IAM management keeps secure communication simple as you add more services.

Conclusion

Google service accounts give you a secure, scalable way to do M2M JWT authentication without managing shared secrets. Generate the JWT with custom claims in one service, verify it in another, and you get strong auth with very little added complexity. The NestJS examples above are a practical starting point for wiring this into your own services.