63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
## MODIFIED Requirements
|
|
|
|
### Requirement: OAuth2/OIDC Flow
|
|
The system SHALL support OAuth2/OIDC authentication via Authentik and SHALL validate Authentik-issued tokens via JWKS before creating local sessions.
|
|
|
|
#### Scenario: User login
|
|
- GIVEN a user clicks the login button
|
|
- WHEN the frontend redirects to Authentik authorization endpoint
|
|
- THEN the user authenticates with Authentik
|
|
- AND Authentik redirects back with authorization code
|
|
|
|
#### Scenario: Token exchange and validation
|
|
- GIVEN Authentik has redirected with authorization code
|
|
- WHEN the callback endpoint receives the code
|
|
- THEN it exchanges the code for provider tokens
|
|
- AND verifies token signature and claims using Authentik JWKS
|
|
- AND upserts the local user account
|
|
- AND mints internal access and refresh tokens
|
|
|
|
### Requirement: Session Security
|
|
The system SHALL protect sessions using httpOnly cookies and SHALL apply secure cookie defaults by environment.
|
|
|
|
#### Scenario: Cookie attributes in production
|
|
- GIVEN successful authentication in production
|
|
- WHEN cookies are set
|
|
- THEN access_token cookie SHALL be httpOnly
|
|
- AND access_token cookie SHALL have Secure flag
|
|
- AND access_token cookie SHALL have SameSite=strict
|
|
- AND refresh_token cookie SHALL have the same attributes
|
|
|
|
#### Scenario: Cookie attributes in localhost development
|
|
- GIVEN successful authentication in localhost development
|
|
- WHEN cookies are set
|
|
- THEN access_token cookie SHALL be httpOnly
|
|
- AND access_token cookie SHALL have Secure=false
|
|
- AND access_token cookie SHALL have SameSite=lax
|
|
- AND refresh_token cookie SHALL have the same attributes
|
|
|
|
### Requirement: Token Refresh
|
|
The system SHALL support automatic token refresh with server-side refresh token storage, rotation, and revocation.
|
|
|
|
#### Scenario: Access token expiration
|
|
- GIVEN a user has an expired access token
|
|
- WHEN the user makes an authenticated request that can refresh
|
|
- THEN the system validates the refresh token against non-expired, non-revoked DB state
|
|
- AND rotates the refresh token
|
|
- AND issues a new internal access token
|
|
|
|
#### Scenario: Refresh token reuse detection
|
|
- GIVEN a refresh token has already been rotated or revoked
|
|
- WHEN it is presented again to the refresh endpoint
|
|
- THEN the system rejects the request with unauthorized status
|
|
- AND invalidates the token chain for the session
|
|
|
|
### Requirement: Session Termination
|
|
The system SHALL support explicit logout with refresh token invalidation.
|
|
|
|
#### Scenario: User logout
|
|
- GIVEN an authenticated user
|
|
- WHEN the user clicks logout
|
|
- THEN all auth cookies are cleared
|
|
- AND the refresh token is invalidated in server-side storage
|