[Spring] 로그인처리

1. 개요

 로그인 처리를 기본적으로 프론트에서 form 처리와 post처리를 통해 진행하려고 했었으나

구글 outh 인증을 통해 진행하도록 노선을 잡았고,

 더욱이 jwt를 통해 사용자 인증권한에 대한 자원소모를 줄이고자했던 노력으로 인해 좀 더 복잡해졌던 내용을 정리.

 

 

2. 오류

2-1) JWT,, HttpOnly 쿠키에 대한 이해부족

사용자 요청시 검증에 관련된 로직처리방법을 고민하던 부분.

사용자의 구글 인증 후 사용자의 정보를 DB에 저장, 이후 jwt 값을 전달한 뒤,

리액트로 구현한 프론트의 store에 저장할 경우, 새로고침하면 사라진다는 문제로 인해

httpOnly 쿠키를 사용하게됨.

새로고침이나, 세션쿠키, 사용자가 브라우저의 쿠키를 삭제하는 경우,

기한만료가 아닌이상 유지되는것을 알았다.

 

2-2) DB 인덱스키 사용 오류

postgres를 활용하여 모든 테이블에 uid로 활용할 컬럼을 bigserial로 선언하였으나

토큰의 값을 직접 사용하는것이 설계나, 구현하는것이 직관적이지 않나?

라는 생각으로 모두 삭제 했으나,

DB의 인덱싱 구성시 많은 비용으로 불리할것이라고 판단하여

컬럼을 재생성 후, 클라이언트의 httpOnly 쿠키 발급시, 토큰 값과 토큰 uid를 발급하도록 수정하였다.

 

2-3) 로직 설계 오류

 가장 고민됐던 부분.

메시지 파싱, 동작의 구동 범위를 어떻게 잡아야하는 것인지, 고민,고심이 많았다.

 최종적으로 크게 3개의 범위로 나누게 됐다.

 컨트롤러에서는 기본적으로 메시지포맷팅 담당하도록 했고,

서비스 부분에서는 메시지의 내용을 구성.

잡다한 로직은 하나의 동작만을 하도록 변경하게됐다.

일단 시작하고 보자는 형식으로 진행했었는데,

 크고 작은 문제로 유지보수가 어려운 코드들이 많아지는것이 눈에 보이기 시작했는데,

 처음 만들때 생각했던 동작에 연관된 내용으로 메소드명을 작성하다보니,

갈수록, 코드를 다시보지 않는이상, 동일하거나, 비슷한 동작을 하는 경우들이 많았는데,

 생각해보니 전체 코드를 작성하지 않고, 하나의 클래스를 작성할때 이렇게도,

저렇게 써도 생성될 수 있도록 만들어서 그랬던 것 같다.

 

 예를 들면, 요청 전처리, 후처리 필터링 클래스가 현재 구현되어있진 않지만

리프레시 토큰의 재생성 요청이 들어오면,

 서비스 로직 부분에서 하위 서비스 로직에 구현되어있는,

DB로직(리프레시 토큰 삭제, 리프레시 토큰 등록) 각각의 메서드를 활용하면 됐었지만

 하위 서비스의 동작으로 새로 기존 리프레시 Uid를 유지한채 토큰값을 변경하는 동작을 추가하고

이를 구현하고 있었다.

 

3. 해결

가장 기초적인 커밋의 내용부터 수정하게 되었다.

신규기능 추가, 코드 리팩토링, 문서 수정을 모두 하나로 통일하여

"시간" "작성자" "내용" 

"세부내용"

으로 작성했으나

 

시간과 작성자는 깃 커밋, 로그를 확인하면 누가 언제 수정했는지 볼 수 있으니 제외하였고

간결하게 "타입" : "내용" 을 작성하는것으로 간략화하였다.

- 타입: 내용으로 작성  
1. feat: 새로운 기능    
2. fix: 버그 수정    
3. refactor: 리팩토링
4. docs: 문서 수정    
5. style: 코드 포맷팅 (세미콜론, 줄바꿈 등)  
6. test: 테스트 코드 추가/수정    
7. chore: 빌드/설정 등 코드 외 변경

 

이외에 일자별 진척사항과 문제 발생사항을 옵시디언을 활용하여 정리,

mermaid문법을 활용해서 시각화하는것이 도움이 됐고,

간단한 문제라고 생각했으나 생각보다 더 꼬이는 경우가 많았는데,

이 경우에는 수기로 메모하여 문제가 생기는 부분, 문제가 생길거라 예상되는 부분을 찾기 쉬웠다.

 

(로그인 유지 방법 - 초기 구상안)

 

(로그인 순서도 - 초기 구상안)

 

 

 

DB에서는 토큰 uid를 다시 활용하도록 하였고,

httponly쿠키를 활용하여 유저측의 xss 공격을 방지함과 더불어

sha256 단방향 해시 알고리즘을 활용하여,

토큰값 자체를 저장할때보다 사용하는 DB 비용을 감소시키며, 안정성을 높였다고 판단된다.

 

 

 httpOnly 쿠키를 활용함으로써,

 프론트에서 현재 발급된 토큰값에 접근할 수 없게됐다.

사용자 입장에서 인증토큰의 유효기간을 알 수 없는 상황이 되었는데,

 이를 해결하기 위해,

 서버측에서 요청의 전,후 처리과정에서 사용자 인증, 권한여부를 검토,

 요청 후처리 과정에서 jwt와 인증토큰 기간 만료 여부를 판단하여,

다시 httpOnly쿠키에 심어주는 동작을 하게 된다.

 

 

추가 보완 장치

안정장치로 사용자 접속정보 (ip, user-Agent)를 저장하여

여러 기기의 동시 접속을 허용함과 동시에 다른 장치의 세션을 제어할 수 있으며,

아이디별 접속기록, 세션별 행동을 간단한 로그로 남기도록 추가적인 테이블을 구성했다.