API_KEY vs Service Account ( JWT )
When should you use API key and when should you use a service account?
Most of the time people tend to go for the API_KEY because its simpler. But using a service account – JWT – is more beneficial and it is really worth the time you put in setting it up.
Basically, you can use API keys for quick testing or public access but for more rigorous tasks you should almost always set up a service account.
Here is the drilldown:
API Key Limitations ποΈ
- No Authentication
- Only identifies your project, not who’s making the request
- Anyone with the key can use it (risk of quota theft if exposed)
- No Fine-Grained Permissions
- Cannot restrict access to specific resources (e.g., only allow tagging for certain folders)
- Rate Limits
- Stricter default quotas (e.g., 1,800 requests/minute vs 15,000 with JWT)
- No User Impersonation
- Cannot act on behalf of users (always acts as “anonymous”)
- No Audit Logs
- Harder to track who made requests in Google Cloud logs
JWT (Service Account) Limitations π
- Complex Setup
- Requires generating RSA keys and handling token expiration (~1 hour)
- Private Key Security
- Leaked keys grant full access to the service account’s permissions
- Must be securely stored (use Google Secret Manager in production)
- Initial Latency
- Each JWT must be generated and exchanged for an access token (~300ms overhead)
- Scope Restrictions
- Must pre-define OAuth scopes (e.g.,
https://www.googleapis.com/auth/cloud-vision
)
- Must pre-define OAuth scopes (e.g.,
- Project-Level Access
- By default, can access all resources the service account has permissions for
When to Use Each
Use API Key When π | Use JWT When π |
---|---|
Public/unauthenticated APIs | Accessing private/user-specific data |
Simple prototypes/testing | Production environments |
Read-only public data | Need fine-grained IAM permissions |
Anonymous access is okay | Acting on behalf of users/service accounts |
Key Differences Table
Feature | API Key | JWT (Service Account) |
---|---|---|
Authentication | None | OAuth 2.0 |
Permission Control | None | IAM Roles |
Rate Limits | Lower | Higher |
Security | Weak | Strong |
Setup Complexity | Easy | Moderate |
Best For | Public data | Private/authenticated workflows |
to wrap up:
-
Use JWT if you need:
-
Higher quotas
-
Audit trails
-
To restrict access to specific Cloud Storage buckets/folders
-
-
Use API Key only for:
-
Quick testing
-
Publicly accessible images
-
When you donβt need IAM controls
-
Detailed comparison
Here’s a detailed comparison between API Keys and JWT (Service Accounts) for Google Vision API, focusing on usage limits, capabilities, and practical implications:
1. Usage & Authentication
Feature | API Key | JWT (Service Account) |
---|---|---|
Authentication Method | Project identifier (no user context) | OAuth 2.0 with cryptographic signing |
Best For | Public/unauthenticated requests | Private/authenticated workflows |
Setup Complexity | Copy-paste key | Generate RSA keys, handle token expiry |
2. Rate Limits & Quotas (Google Vision API)
Limit Type | API Key | JWT (Service Account) |
---|---|---|
Default Quota | ~1,800 reqs/minute | ~15,000 reqs/minute |
Max Image Size | 10MB (both) | 10MB (both) |
Concurrent Requests | Lower (shared project quota) | Higher (dedicated quota) |
Quota Increase | Hard to obtain | Easier with paid plans |
Note: Actual limits vary by Google Cloud project tier.
3. Capabilities & Access Control
Capability | API Key | JWT (Service Account) |
---|---|---|
IAM Permissions | None (all-or-nothing) | Fine-grained (per-bucket/folder access) |
User Impersonation | No | Yes (can act as specific service account) |
Audit Logging | Limited to project-level | Detailed per-request logs |
Private Data Access | Only public resources | All authorized resources |
Cost Tracking | Project-wide | Per-service-account |
4. Security Comparison
Aspect | API Key Risks | JWT Risks |
---|---|---|
If Leaked | Anyone can use until revoked | Must rotate RSA keys |
Revocation | Instant (delete key) | Delay (tokens valid until expiry) |
Encryption | None (plaintext) | RSA-256 signed |
Recommended Use | Temporary prototypes | Production environments |
5. Practical Scenarios
When to Use API Key:
-
Quick prototyping
-
Public image analysis (e.g., blog post images)
-
Free-tier testing
When to Use JWT:
-
Processing private user uploads
-
High-volume production workloads
-
Need IAM roles (e.g., only allow tagging in
/client-uploads/
)
6. Code Examples
API Key Simplicity
const visionUrl = `https://vision.googleapis.com/v1/images:annotate?key=YOUR_API_KEY`; // No auth headers needed
JWT Power (with error handling)
const {JWT} = require('google-auth-library'); const jwtClient = new JWT( serviceAccount.client_email, null, serviceAccount.private_key, ['https://www.googleapis.com/auth/cloud-vision'] ); // Auto-refreshes tokens const tokens = await jwtClient.authorize();
Recommendation
-
Stick with JWT for:
-
Higher quotas (avoids rate limits)
-
Future-proofing for private images
-
Better audit trails
-
-
Fix your JWT errors by:
-
Ensuring the private key is PEM-formatted with
\n
line breaks -
Verifying the service account has related API enabled
-
Using a fresh key pair (old keys may be corrupted)
-