ReSSO v0.9.80

접근 권한을 내주는 작업에는 비밀번호를 다시 묻습니다. 관리 콘솔 세션은 쿠키를 가진 사람이 곧 관리자인 자격 증명입니다. 대시보드를 읽는 데는 타당한 거래지만, 비밀번호 재설정·Role 부여·Secret 회전·API 키 발급처럼 세션보다 오래 사는 접근을 내주는 작업에는 그렇지 않습니다.

보안

• 아홉 개 작업이 직전 5분 안의 비밀번호 확인을 요구합니다. Realm 생성과 설정 변경, 사용자 비밀번호 재설정, Role 매핑 교체, Client Secret 회전, 서명 키 회전, LDAP 공급자 삭제, 개인 API 키 생성과 회전입니다. 읽기와 나머지 변경 작업은 묻지 않습니다 — 모든 곳에서 물으면 창을 읽지 않고 넘기게 되고, 그러면 묻는 일 자체가 의미를 잃습니다.
• 콘솔은 한 번만 묻고 하던 일을 그대로 잇습니다. 거절을 화면마다 처리하면 아홉 곳에 같은 대화 상자가 생기고 열 번째가 빠집니다. API 계층이 거절을 받아 묻고, 요청했던 작업을 그대로 다시 보냅니다. 여러 요청이 동시에 거절당해도 창은 하나입니다 — 일괄 작업이 열네 번 거절당했다고 대화 상자를 열네 개 띄우는 것은 보안 장치가 아닙니다.
• 주는 것은 시간창이지 수명이 아닙니다. 비밀번호를 확인해도 세션은 갱신·교체되지 않고 만료 시각도 그대로입니다. 비밀번호를 다시 쳐서 세션을 무한히 연장할 수 없습니다.
• 실패는 REAUTHENTICATION 이벤트로 남습니다. 탈취된 콘솔 세션을 두드리는 흔적이 로그인 화면의 일상적인 실패들 사이에 묻히지 않습니다. 로그인과 같은 IP·계정 제한과 계정 잠금이 그대로 적용됩니다.
• API로 직접 호출하면 403 + reauthentication_required로 거절되고, POST /api/v1/auth/reauthenticate로 확인한 뒤 같은 요청을 다시 보내면 됩니다. OpenAPI 문서의 해당 operation에 이 응답이 기재됩니다 — 문서는 라우터가 쓰는 것과 같은 목록에서 생성되므로 둘이 어긋날 수 없습니다.

스키마

• sso_sessions.authenticated_at이 생깁니다(마이그레이션 015). 세션이 언제 시작됐는지와 언제 마지막으로 본인을 증명했는지는 지금까지 같은 사실이어서 auth_time과 max_age를 created_at으로 답했는데, 더는 같은 사실이 아닙니다. 묻는 쪽은 전부 이 컬럼을 읽습니다.
• 업그레이드는 created_at에서 값을 채웁니다 — 열려 있던 세션에 하지도 않은 증명을 주지 않습니다. 즉 업그레이드 직후 auth_time과 max_age 동작은 이전과 동일합니다.

확인

• 라우터를 순회해 목록에 있는 아홉 개는 오래된 세션을 반드시 거절하고, 목록에 없는 나머지는 반드시 통과하는지 양쪽으로 검사합니다. 목록의 오타도 잡습니다. 가드를 지우는 것, 엉뚱한 곳으로 번지는 것, 만료를 없애는 것 — 셋 다 망가뜨려 실패를 확인했습니다.
• 콘솔 쪽 6건(재시도·취소·오입력·동시 요청·다른 거절과의 구별)도 각각 망가뜨려 확인했습니다.