🔐인증/인가 서버 - 소셜 -> 일반으로 전향하기(3)

프로젝트 설명 및 설계

🧸기본 설정

• 이름 : AuthServer7
• 버전 : SpringBoot 2.6.8 & JDK 11
• 패키지 : me.ver.Authserver7
• 의존성

- JPA
- Security
- Validation
- Web
- Redis
- Devtools
- Lombok
- MySQL
- Jsonwebtoken(api, impl, jackson)
- (테스트) Test, SecurityTest

• DB 관련
  -> 환경 변수 : DB_PASSWORD, DB_URL, DB_USERNAME으로 설정
  -> DB 이름 : authserver7

---

🧸내용 정리

1. JWT

• 토큰 확인 가능 사이트(jwt.io)
• Header + Payload + Signature
• Header : Signature 해싱 알고리즘 정보(alg : HS256)
• Payload : 서버 - 클라이언트 간의 실제 사용 정보 저장(iss: 토큰 발급자, exp : 토큰 만료 시간)
• Signature : 토큰 유효성 검증 문자열 저장(헤더 + 페이로드 + 시크릿 키 구조로 생성한다 -> 시크릿 키는 서버에서 관리함)
  
  
• AccessToken & RefreshToken : 엑세스 토큰의 유효시간 짧게, 리프레시 토큰 함께 발급
• RefreshToken의 저장 : 이 토큰의 저장은 MySQL 사용(보통은 Redis임)
• 로그아웃 기능은 MySQL만으로 구현하기 매우 어려움 -> 블랙리스트 기능을 사용하기 위해 Redis를 사용하는 것임.

---

2. 흐름 정리(요청 및 응답을 반드시 이렇게 한다라고 고정한 것은 절대 아님을 미리 알려드립니다.)

<회원가입>

• Request : POST { email, password, username, nickname }
• Response : { email, username, nickname, authorities(권한) }
• 예시
  

---

<로그인>
1. 로그인 요청
2. DB 접근 & 유저 확인(검증)
3. 토큰 발급
4. 응답

5. 데이터 요청
6. Access Token 유효성 검증
7. 응답(요청한 데이터에 대한 내용)

[ 액세스 토큰 만료시 ]
1. 데이터 요청
2. 엑세스 토큰 만료 여부 확인
3. 응답
4. 엑세스 토큰 발급 요청
5. 리프레시 토큰을 통해 유저 확인, 새로운 액세스 토큰 발급
6. 응답

• Request : POST { email, password }
• Response : { grantType, accesstoken, refreshtoken, accessTokenExpiresIn }
• 예시
  

---

<로그아웃>

• Request : GET (액세스 토큰으로)
• Response : 로그아웃 성공 / 실패 시 다음 첨부
• 예시
  
  

---

<토큰 재발급>

• Request : POST { accesstoken, refreshtoken }
• Response : { grantType, accesstoken, refreshtoken, accessTokenExpiresIn }
• 예시
  

---

<정보 조회>

• Request : GET (엑세스 토큰으로)
• Response : { email, username, nickname, authorites }
  

---

<정보 수정>

• Request : PUT { nickname } + 엑세스 토큰
• Response : { email, username, nickname, authorities }
• 예시
  

---

<회원 탈퇴>

• Request : DELETE (엑세스 토큰)
• Response : 회원 탈퇴 성공 / 실패 시 다음 첨부
• 예시
  
  

---

🧸요구사항 분석(간략하게)

1. 유저 관련

• 회원가입
• 로그인
• 토큰 재발급
• 로그아웃
• 정보 조회(해당 유저만)
• 정보 수정(해당 유저만)
• 회원 탈퇴
• 이메일은 절대 중복되지 않도록 함.(이메일로 관리)

2. 그 외

• POSTMAN을 통해 테스트 및 검증

🧸DB 테이블 설계

✅ 예상한 버전(이 버전 역시 확정 버전은 아닙니다.)

⚙️ 고려한 사항들

✒️ USER_LOG(파일로 저장할 예정)에 대해서 큰 필요성을 느끼지 못해 우선 개발에서 제외시켰음.
✒️ 권한에 대한 테이블 이름 변경 : ROLE -> authority & user_authority로 구분
(ROLE_ADMIN, ROLE_USER 등으로 ''을 정할 경우 혼동을 우려하여 authority로 테이블 이름 변경)
✒️ auto_increment -> hibernate_sequence 테이블의 사용[sequence(next_val)]

-> 주로 오라클에서 사용하기는 하지만, auto_increment를 사용하면 해당 테이블에 접속하여 확인하면 되지만 혹시나 번호가 꼬여있을 가능성을 배제할 수 없었다.(실제로 auto를 믿었다가 완전히 꼬인경우가 많았다..)
-> 또한 별도의 테이블이 없어 순서가 헷갈리는 경우가 많았고 설계를 확실하게 검증하며 하는 것을 선호하는 편이라 next_val을 사용하는 시퀀스 전략을 써서 ID 값을 부여함.

✅ 수정 버전(현실적으로 내가 고려하며 개발할 수 있는 수준으로 개발하고자 했습니다.)

---