Understanding Scute’s Structure
The Basics
Scute organizes users and permissions in a simple hierarchy:- Workspace: “Acme Corp” (your company)
- App: “Acme Mobile App” (your customer-facing app)
- App Users: Your end customers (john@customer.com, jane@customer.com)
- Users: Your team members (admin@acme.com, dev@acme.com)
Key Concepts
- Workspace: Your organization’s account on Scute
- App: Each application you build (mobile app, web app, etc.)
- App Users: Your end customers who log into your apps
- Users: Your team members who manage the workspace
JWT Token Structure
When a user successfully authenticates, Scute issues a JWT token with the following structure:Token Claims Explained
| Claim | Description | Example |
|---|---|---|
uuid | App User ID - identifies the authenticated user | "usr_1234abcd" |
aid | App ID - your application identifier | "app_5678efgh" |
uid | Session ID - unique identifier for this login session | "sess_9012ijkl" |
wid | Workspace ID - your organization’s identifier | "ws_3456mnop" |
crid | Credential ID - method used to authenticate (WebAuthn, etc.) | "cred_7890qrst" |
exp | Expiration - when the token expires | 1640995200 |
iat | Issued At - when the token was created | 1640991600 |
Offline JWT Verification (Recommended)
Offline verification is faster and more scalable as it doesn’t require API calls to validate tokens.Step 1: Get the Public Key
Fetch your app’s public key for JWT verification (this is a public endpoint):Step 2: Offline JWT Verification
Step 3: Using JWKS (Recommended for Production)
JWKS (JSON Web Key Set) provides automatic key rotation support:Key Points for Offline Validation
✅ Benefits
- 🚀 Performance: No API calls required for each validation
- 🔒 Security: Cryptographically secure verification
- ⚡ Scalability: No rate limits on token validation
- 🌐 Offline Support: Works without internet connectivity
⚠️ Important Considerations
-
Cache Public Keys Wisely
-
Validate Token Claims
-
Handle Key Rotation
Online Verification (Alternative)
If you prefer server-side validation or need additional user data, use online verification:Endpoint
Example Implementation
Online vs Offline Verification
| Method | Speed | Data Available | Internet Required | Rate Limits |
|---|---|---|---|---|
| Offline | ⚡ Fast | Basic claims only | ❌ No | ❌ None |
| Online | 🐌 Slower | Full user data | ✅ Yes | ✅ Standard API limits |
Best Practices
Security Recommendations
- Use HTTPS Only: Never transmit tokens over HTTP
- Validate Audience: Always check the
aidclaim matches your app - Check Expiration: Validate
expclaim before processing - Store Securely: Use secure storage for tokens on client-side
Performance Optimization
- Cache Public Keys: Refresh every 1-6 hours
- Use Offline Verification: For high-traffic applications
- Connection Pooling: Reuse HTTP connections for online verification
- Error Handling: Gracefully handle network failures
Example: Complete Verification Function
Troubleshooting
Common Issues
“Invalid signature” Error- Check that you’re using the correct public key for your app
- Ensure you’re using the RS256 algorithm
- Verify the token hasn’t been modified
- Check system clock synchronization
- Token has a limited lifetime (typically 1 hour)
- Request a new token using refresh flow
- Ensure the
aidclaim matches your app ID - Token might be intended for a different app
- Check API endpoint URL is correct
- Verify internet connectivity
- Ensure proper Authorization header format