auth-testing
Skill447 starsChanged 3 months agoMITView on GitHub
Test OAuth2 token refresh and session expiry locally. Use when working on auth, tokens, SSO, OIDC, or session management features.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Test OAuth2 authentication flows locally using the built-in OIDC server.
- Distinctive: line 34
Test that tokens refresh automatically before expiry.
- Distinctive: line 47
Test that sessions expire and force re-login.
- Distinctive: line 56
Should redirect to OIDC login page
- Distinctive: line 60
Test long-lived sessions with only token refresh.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Auth Testing Skill
Test OAuth2 authentication flows locally using the built-in OIDC server.
Quick Start
pnpm dev:with-authThis starts:
- Vite dev server: http://localhost:3000
- UI Server (Go): http://localhost:8081
- OIDC Server: http://localhost:8889
- Temporal Server: http://localhost:7233
Configuration Files
| File | Purpose |
server/config/with-auth.yaml | UI server auth settings (maxSessionDuration, providers) |
utilities/oidc-server/support/configuration.ts | OIDC server TTLs (token expiry, session duration) |
Testing Scenarios
1. Token Refresh
Test that tokens refresh automatically before expiry.
Config: AccessToken TTL (60s) < maxSessionDuration (2m)
Steps:
- Login at http://localhost:3000
- Open browser DevTools > Network tab
- Wait ~60 seconds
- Observe
/auth/refreshrequest that renews tokens
2. Session Expiry
Test that sessions expire and force re-login.
Config: maxSessionDuration = Session TTL (both 2m)
Steps:
- Login at http://localhost:3000
- Wait 2 minutes
- Make any API request (navigate, refresh)
- Should redirect to OIDC login page
3. Unlimited Session
Test long-lived sessions with only token refresh.
Config changes:
# server/config/with-auth.yaml
auth:
maxSessionDuration: 0 # Disable session limit// utilities/oidc-server/support/configuration.ts
ttl: {
Session: 60 * 60 * 24, // 1 day
}Max Session Duration
The maxSessionDuration config enforces a hard limit on how long a user can stay logged in, independent of token expiry.
How it works
- On login: Server sets
session_startcookie with current timestamp - On each request: Server validates session age against
maxSessionDuration - On expiry: Server returns 401, UI redirects to SSO login
Config location
# server/config/with-auth.yaml
auth:
enabled: true
maxSessionDuration: 2m # Duration string (e.g., 30m, 1h, 24h)
# Set to 0 or omit to disableDifference from token expiry
| Mechanism | Controls | Behavior on expiry |
| Token TTL | How often tokens refresh | Silent refresh via /auth/refresh |
| maxSessionDuration | Total session lifetime | Full re-authentication required |
Use cases
- Security compliance: Force re-auth every N hours regardless of activity
- Testing: Set short duration (2m) to quickly test session expiry flow
- Production: Set longer duration (8h, 24h) based on security requirements
Key Relationships
AccessToken TTL < maxSessionDuration → Enables token refresh
Session TTL = maxSessionDuration → Forces re-auth at OIDC on expiry
RefreshToken TTL > Session TTL → Allows refresh within sessionCurrent Default Values
| Setting | Value | Location |
| Access Token TTL | 60s | OIDC config |
| ID Token TTL | 60s | OIDC config |
| Refresh Token TTL | 1 day | OIDC config |
| OIDC Session TTL | 2m | OIDC config |
| Max Session Duration | 2m | UI server config |
Debugging
View auth logs
The Go server logs token validation:
[Auth] Setting refresh token cookie (length: X)
[JWT Validation] Token valid, expires at X (time remaining: X)Check cookies
In browser DevTools > Application > Cookies:
user0,user1... - Base64 encoded user data (short-lived)refresh- HttpOnly refresh token (long-lived)session_start- Session start timestamp (HttpOnly)
Test endpoints
# Get OIDC discovery
curl http://localhost:8889/.well-known/openid-configuration
# Manual token refresh (requires valid refresh cookie)
curl -X GET http://localhost:8081/auth/refresh --cookie "refresh=<token>"Related Files
server/server/route/auth.go- Auth routes and callbacksserver/server/auth/auth.go- Token validation and session managementserver/server/config/config.go- Auth config structsrc/lib/utilities/auth-refresh.ts- Client-side refresh logic
In this repository7 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- local-temporalSkill
- proto-codegenSkill
- serverless-worker-awsSkill
- setup-worktreeSkill
- svelte-migrateSkill
- system-nexus-operationSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

