add stories
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
# Create and Manage API Tokens
|
||||
|
||||
**ID:** DEV-001
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to create and manage API tokens so that I can integrate my applications with the identity provider programmatically.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Developer can create new API tokens with custom names
|
||||
- [ ] Token is shown once at creation (cannot be retrieved later)
|
||||
- [ ] Developer can set token expiration (or no expiration)
|
||||
- [ ] Developer can set token scopes/permissions
|
||||
- [ ] List all tokens with creation date and last used
|
||||
- [ ] Revoke individual tokens
|
||||
- [ ] Revoke all tokens at once
|
||||
- [ ] Rate limiting information shown per token
|
||||
|
||||
## Technical Notes
|
||||
- ApiTokenManager exists with basic infrastructure
|
||||
- `loginWithApiToken` endpoint available
|
||||
- Need UI for token management (currently backend only)
|
||||
- Tokens should be hashed before storage (show once)
|
||||
- Consider token prefixes for easy identification (idp_...)
|
||||
|
||||
## Related TODOs
|
||||
- Partial implementation in ApiTokenManager
|
||||
@@ -0,0 +1,28 @@
|
||||
# Comprehensive SDK Documentation
|
||||
|
||||
**ID:** DEV-002
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want comprehensive documentation for the IDP client SDK so that I can integrate authentication into my applications quickly and correctly.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Getting started guide with installation and setup
|
||||
- [ ] Authentication flow explanations with diagrams
|
||||
- [ ] API reference for all client methods
|
||||
- [ ] Code examples for common use cases
|
||||
- [ ] TypeScript type definitions documented
|
||||
- [ ] Error handling guide with error codes
|
||||
- [ ] Migration guides for version upgrades
|
||||
- [ ] Interactive API playground/sandbox
|
||||
|
||||
## Technical Notes
|
||||
- `ts_idpclient/` contains the client SDK
|
||||
- README.md has basic usage but needs expansion
|
||||
- Generate API docs from TypeScript using TypeDoc
|
||||
- Host documentation on dedicated site or GitHub pages
|
||||
- Consider OpenAPI/Swagger spec for REST endpoints
|
||||
|
||||
## Related TODOs
|
||||
- New feature - documentation enhancement
|
||||
@@ -0,0 +1,28 @@
|
||||
# Configure Webhook Notifications
|
||||
|
||||
**ID:** DEV-003
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to configure webhooks so that my application is notified in real-time when authentication events occur.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Register webhook endpoints with URL and secret
|
||||
- [ ] Select which events to subscribe to
|
||||
- [ ] Events include: user.created, user.login, user.logout, org.member.added, etc.
|
||||
- [ ] Webhook payloads include event type, timestamp, and relevant data
|
||||
- [ ] Signature verification using shared secret (HMAC)
|
||||
- [ ] Retry logic for failed deliveries (exponential backoff)
|
||||
- [ ] Webhook delivery logs with success/failure status
|
||||
- [ ] Test webhook button to send sample event
|
||||
|
||||
## Technical Notes
|
||||
- Create Webhook model with URL, secret, events, and status
|
||||
- Queue webhook deliveries for reliability (consider bull/bullmq)
|
||||
- Sign payloads with HMAC-SHA256
|
||||
- Timeout for webhook delivery (10 seconds)
|
||||
- Dashboard for delivery monitoring and debugging
|
||||
|
||||
## Related TODOs
|
||||
- New feature - event-driven integration
|
||||
@@ -0,0 +1,28 @@
|
||||
# Proper App ID Initialization
|
||||
|
||||
**ID:** DEV-004
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to properly register my application with a unique App ID so that the identity provider can identify and configure my app correctly.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Developer can register new applications
|
||||
- [ ] Each app gets unique App ID and App Secret
|
||||
- [ ] Configure allowed redirect URIs per app
|
||||
- [ ] Configure allowed origins (CORS) per app
|
||||
- [ ] App-specific settings (token expiry, etc.)
|
||||
- [ ] View app analytics (logins per app)
|
||||
- [ ] Regenerate app secret if compromised
|
||||
- [ ] Delete/deactivate applications
|
||||
|
||||
## Technical Notes
|
||||
- Current client has `id: ''` placeholder (TODO in code)
|
||||
- Need Application model in database
|
||||
- App credentials similar to OAuth client credentials
|
||||
- Validate redirect URIs to prevent open redirector attacks
|
||||
- App ID should be included in JWT claims
|
||||
|
||||
## Related TODOs
|
||||
- `ts_idpclient/classes.idpclient.ts:30` - `id: '', // TODO`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Register OAuth Client App
|
||||
|
||||
**ID:** DEV-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to register my application as an OAuth client so that users can authorize my app to access their data using standard OAuth 2.0 flows.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Register OAuth 2.0 client application
|
||||
- [ ] Support Authorization Code flow
|
||||
- [ ] Support PKCE for public clients (mobile/SPA)
|
||||
- [ ] Configure allowed scopes per client
|
||||
- [ ] Consent screen customization
|
||||
- [ ] Token endpoint for code exchange
|
||||
- [ ] Refresh token support
|
||||
- [ ] Client credentials flow for server-to-server
|
||||
|
||||
## Technical Notes
|
||||
- OAuth keywords in package.json suggest this is planned
|
||||
- Implement OAuth 2.0 authorization server endpoints
|
||||
- Scopes: openid, profile, email, organizations
|
||||
- Consider OpenID Connect for identity layer
|
||||
- PKCE is required for mobile and SPA security
|
||||
|
||||
## Related TODOs
|
||||
- New feature - OAuth server implementation
|
||||
@@ -0,0 +1,27 @@
|
||||
# Understand API Rate Limits
|
||||
|
||||
**ID:** DEV-006
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to understand and monitor API rate limits so that I can build applications that respect limits and handle throttling gracefully.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Clear documentation of rate limits per endpoint
|
||||
- [ ] Rate limit headers in API responses (X-RateLimit-*)
|
||||
- [ ] Different limits for different API token tiers
|
||||
- [ ] Dashboard showing current usage vs limits
|
||||
- [ ] Alerts when approaching rate limits
|
||||
- [ ] Retry-After header when rate limited
|
||||
- [ ] Ability to request limit increase
|
||||
|
||||
## Technical Notes
|
||||
- Implement rate limiting middleware (consider express-rate-limit)
|
||||
- Store rate limit counters in Redis for distributed systems
|
||||
- Different limits: login attempts, API calls, token operations
|
||||
- Consider sliding window algorithm for smooth limits
|
||||
- 429 Too Many Requests response with helpful error message
|
||||
|
||||
## Related TODOs
|
||||
- New feature - API management
|
||||
@@ -0,0 +1,27 @@
|
||||
# Validate JWTs in My Application
|
||||
|
||||
**ID:** DEV-007
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want clear guidance and tools to validate JWTs issued by the identity provider so that I can securely authenticate users in my backend services.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Public key endpoint for JWT validation (JWKS format)
|
||||
- [ ] Documentation explaining JWT structure and claims
|
||||
- [ ] Example code for validation in multiple languages
|
||||
- [ ] Key rotation with multiple valid keys during transition
|
||||
- [ ] Token introspection endpoint for server-side validation
|
||||
- [ ] Clear error messages for invalid tokens
|
||||
- [ ] Guidance on caching public keys
|
||||
|
||||
## Technical Notes
|
||||
- `getPublicKeyForValidation` endpoint exists
|
||||
- Consider standard JWKS endpoint (/.well-known/jwks.json)
|
||||
- OpenID Connect discovery endpoint would help
|
||||
- JWTs contain: sub, email, roles, orgId, exp, iat
|
||||
- Document all custom claims in JWT
|
||||
|
||||
## Related TODOs
|
||||
- Enhancement to existing JWT infrastructure
|
||||
Reference in New Issue
Block a user