Dev 일기장

# 개요

인증/인가를 구현하는 과정에서 세션 방식과 토큰 방식이 있다는 것을 알게되어 정리한다.

내용만 정리하고 별도 코드는 작성하지 않는다.

지적, 오타 등 환영합니다..

# 인증? 인가?

영어로 하면

• 인증: Authentication
• 인가: Authorization 

사실 더 헷갈린다..

내가 이해한 것은 다음과 같다.

• 인증: 로그인
• 인가: 사용자의 권한 확인 → 권한에 맞는 응답

예를 들어서 얘기해보자면

• 어떤 서비스의 회원 리스트를 보고싶은데 일반 회원은 활성화된 회원 리스트만 볼 수 있고, 관리자는 탈퇴하거나 정지된 회원들 리스트도 볼 수 있다고 하자.
  • 인증: 로그인을 통해 내가 이 서비스의 회원이라는 것을 인증받는다.
  • 인가: 내 권한을 확인하여 내가 일반 회원이라면 활성화된 회원 리스트만, 관리자라면 모든 회원 리스트를 볼 수 있도록 인가받는다.

# 세션

HTTP는 Stateless 프로토콜이다. 즉, 각 요청이 독립적이며, 서버는 이전 요청의 상태를 기억하지 않는다.

• 하지만 웹 애플리케이션에서는 클라이언트의 상태를 유지해야 하는 경우가 많다. (예를 들어, 로그인 상태나 장바구니 목록 등)

이러한 Stateless 특성을 보완하기 위해 세션이 도입되었다. 세션은 세션 ID를 사용하여 클라이언트가 서버와의 상호작용에서 상태를 유지하는 방법이다.

작동 방식

1. 클라이언트가 로그인에 성공하면 세션을 생성한다.
2. 생성된 세션은 서버의 어딘가(메모리, 디스크, 데이터베이스)에 저장되고 클라이언트의 브라우저에 쿠키로 저장한다.
3. 이후 요청에서 브라우저는 쿠키에 세션 ID를 담아서 서버에 함께 보낸다.
4. 서버는 이 쿠키의 세션 ID를 확인하여 해당 클라이언트의 상태를 유지하고, 그에 맞는 응답을 보내준다.

세션을 사용하면 클라이언트의 상태를 지속적으로 유지할 수 있기 때문에 관리에 용이하다는 장점이 있지만 다음과 같은 단점도 있다.

• 세션을 메모리, 파일 시스템, 데이터베이스 등에 저장하고 관리하고 있어서 사용자가 많아짐에 따라 부하가 발생할 수 있다.
  • 메모리에서 관리하는 경우 파일 시스템이나 데이터베이스에 비해 빠르지만, 휘발성이라는 단점이 있다.
  • 파일 시스템이나 데이터베이스에서 관리하는 경우 I/O가 발생하므로 메모리에서 관리하는것에 비해 느리다.
• 서버를 여러 대 두고 운영하는 대규모 서비스의 경우 세션 유지가 어렵다.
  • 사용자 요청이 특정 서버에만 할당되도록 설정하거나, 세션을 중앙에서 관리하도록 설정해야 한다.

이러한 단점을 보완하기 위해 토큰을 통한 인증/인가 방식이 도입되었다.

# 토큰 (JWT)

서버 입장에서 세션 방식의 부담을 해결하기 위해 도입된 방식으로 클라이언트의 상태를 따로 저장할 필요가 없다.

작동 방식

1. 로그인에 성공하면 토큰을 생성한다.
2. 토큰은 서버에 저장하지 않고 클라이언트에 전달된다.
3. 클라이언트는 이후 요청마다 헤더에 이 토큰을 담아서 보낸다.
4. 서버는 해당 토큰을 검증하여 해당 클라이언트를 확인하고, 그에 맞는 응답을 보내준다.

위 흐름만 보면 세션을 통한 방법과 작동 방식이 크게 다르지 않은 것 같은데, 토큰을 통한 인증/인가 방식은 어떻게 서버에 토큰을 따로 저장하지 않고 클라이언트가 보낸 토큰을 검증할 수 있을까?

토큰 구조

토큰은 다음과 같은 구조를 가지고 있으며 암호화 된 3가지 데이터를 이어붙인 형식이다.

{header}.{payload}.{signature}

1. Header
   • typ: "JWT" 고정
   • alg: 해싱 알고리즘으로 signature를 만드는데 사용된 알고리즘이 지정된다 (HS256 등..)
2. Payload
   • 토큰에 담을 정보들이 존재하고, 이를 클레임(claim)이라고 한다.
   • 클레임은 세 가지 유형으로 나뉜다.
     • Registered Claims: JWT 표준에서 정의한 클레임으로 iss(발급자), exp(만료 시간), sub(주제), aud(대상자) 등이 포함된다.
     • Public Claims: 충돌 방지를 위해 IANA(Internet Assigned Numbers Authority) JSON 웹 토큰에 등록되거나 URI로 정의된 클레임이다.
     • Private Claims: 클라이언트와 서버 간에 임의로 정의된 클레임이다.
3. Signature
   • 토큰의 무결성을 검증하는 데 사용된다.
   • 서명은 다음과 같은 과정으로 생성된다.
     • Header와 Payload를 각각 Base64로 인코딩한다.
     • 인코딩된 Header와 Payload를 '.'으로 연결한다.
     • 이 연결된 문자열을 서버 내의 '비밀 키'를 이용하여 Header에서 정의한 알고리즘으로 해싱한다.
     • 해싱한 결과를 Base64 URL로 인코딩하여 서명을 만든다.

토큰이 위와 같은 구조를 가지고 있기 때문에 서버는 클라이언트에게 발급한 토큰을 따로 기억할 필요 없다. 서버는 가지고 있는 '비밀 키'와 JWT 헤더의 알고리즘을 이용해서 해당 토큰을 검증한다. 만약 Payload가 조작되더라도 Signature가 달라지기 때문에 유효하지 않은 것으로 판별할 수 있다.

Signature 값이 일치하고, 만료 기간이 지나지 않았다면 해당 사용자에게 인가를 해준다.

그럼 토큰 방식이 서버에 부담이 줄어드니까 세션 방식 보다 항상 우월하고 항상 좋을까?

# 세션 vs 토큰

세션

세션은 서버 내에서 관리되기 때문에 서버가 사용자의 상태를 제어할 수 있다. (Stateful)

• 안정성: 서버측에서 사용자 상태를 관리하기 때문에 보안상 토큰에 비해 안전하다.
  • 한 기기에서만 로그인이 가능한 서비스를 만드는 경우, PC에서 로그인 한 상태의 사용자가 모바일로 다시 로그인을 하면 기존 세션을 종료함으로써 PC에서 로그아웃할 수 있다.
  • 세션 ID가 탈취되더라도 서버측에서 세션을 제거하거는 등 무효화 처리하면 된다.
• 서버 부담: 서버가 모든 세션을 관리해야하기 때문에 세션 데이터가 증가하면 서버의 부담이 커진다.
  • 세션 저장소를 효율적으로 관리하기 위해 Redis와 같은 In-Memory 데이터베이스를 사용하여 보완할 수 있다.
• 확장성: 서버가 확장되면 세션 관리가 어려워 진다.
  • 로드 밸런싱을 통한 스티키 세션이나 중앙 세션 저장소를 사용하여 모든 서버가 동일한 세션 정보를 공유하도록 하여 보완할 수 있다.

토큰

토큰은 서버에 저장되지 않기 때문에 사용자의 상태를 제어할 수 없다. (Statelsss)

• 안정성: 서버에서 토큰 정보를 별도로 관리하지 않기 때문에 보안상 안전하지 않을 수 있다.
  • 토큰이 탈취되더라도 서버 측에서 토큰을 무효화할 방법이 없다.
  • 짧은 만료 시간의 Access Token과 별도로 저장하는 Refresh Token을 도입하여 보완할 수 있다.
• 서버 부담: 서버가 클라이언트의 정보를 보관하지 않기 때문에 세션에 비해 서버의 부담이 줄어든다.
• 확장성: 서버 간 상태를 공유할 필요가 없기 때문에 세션에 비해 서버 확장에 용이하다.

# 결론

세션과 토큰 방식은 각각 장단점이 있다. 세션 방식은 서버가 사용자의 상태를 제어할 수 있고 보안상 안전하지만 확장성이 떨어진다. 반면 토큰 방식은 서버 부담이 적고 확장성이 뛰어나지만 상태 제어가 어렵고 보안상 위험이 존재할 수 있다.

따라서 운영하려는 서비스의 특성에 따라 적절한 방식을 선택하는 것이 중요하다고 할 수 있다. 또한 각 방식의 단점을 보완하기 위한 전략을 도입하여 보다 안전하고 효율적인 인증/인가를 구현할 필요가 있다. 

추후 Sticky Session, Refresh Token에 대한 포스팅 할 수 있으면 하기..

IntelliJ와 git bash 연동하기

Window에서 IntelliJ를 처음 설치하면 기본 터미널은 윈도우 cmd이다.

기본 cmd에서도 git 명령어가 안 되는 것은 아니지만 그래도 git bash가 더 가시성도 좋고 현재 branch도 표시를 해주니까 git bash로 변경해보자.

Ctrl + Alt + S → Tools → Terminal

Ctrl + Alt + S키는 Settings인데 (File → Settings도 가능) 여기서 Tools → Terminal 탭을 보면 Shell path가 cmd.exe이다. 이것을 git bash로 바꿔주면 끝!

"git bash path" -login -i

본인의 sh.exe파일은 git/bin 디렉토리에 있다. 본인 로컬의 git 경로를 찾아서 넣어주고, 경로에 쌍 따옴표(" ")를 붙여주고 -login, -i를 붙여주면 된다.

"C:\Program Files\Git\bin\sh.exe" -login -i

설정 후 터미널 창을 열면 git bash가 잘 나온다

참 쉽죠?

문제의 시작..

혼자 개발하거나, 그냥 문제풀때는 코드 다 작성 후에 한번의 커밋 후 바로 push했었다.
게다가 그 커밋 메세지도 별 생각없이 막 작성했었음..

대충 써 재껴도 나 혼자니까 별 문제점을 느끼지 못했었는데, 팀 프로젝트를 하면서 멘토님이 말씀하시길

처럼 코딩 컨벤션 지키기, 브랜치 생성, 커밋 메세지, PR 제목 등에서도 팀원들 전부 통일되도록 요구했었다.

왜 필요할까?

개발자도 사람이기 때문에 각자의 스타일이 있다.
간단한 예시로 if, while, for문 등이 한줄로 끝날 때도

for(int i = 0; i < 10; i++) {
    System.out.println("Hello World!");
}

for(int i = 0; i < 10; i++)
    System.out.println("Hello World!");

처럼 {}를 붙이는 경우는 사람도 있고 붙이지 않는 사람도 있다.
또한 변수, 함수 이름을 지을 때도

create_new_user()  
CreateNewUser()  
createNewUser()

처럼 camelCase나 snake_case 등 (헝가리안 쓰는 사람도 있더라..) 개인의 취향, 습관 등에 따라 다 다를 것이다.
이런 스타일이 다 다른 개발자들이 모여서 협업을 하면 어떻게 될까? 코드의 일관성이 사라질 것이다.
따라서 코딩 컨벤션을 정하고 팀원들이 이를 지키는것은 매우 중요하다고 할 수 있다.

코딩 컨벤션의 장점

• 정해진 규칙이 있기 때문에 명칭이나 구조를 빠르고 정확하게 파악할 수 있다.
• 통일된 규약이 있으므로 모든 사람들이 코드를 이해하기 쉽다.
• 불필요한 유지보수가 줄어든다
  즉 쉽게 말해 가독성이 좋아진다! (어? 이거 완전 클린코드..?)

비단 코드에서 뿐만 아니라 Github에서 Issue나 PR작성할 때, 로컬에서 branch나 commit 메세지를 작성할때도 적용된다.

도움을 주는 도구들 (Python)

1. black: 코드 스타일 자동 Formatter
2. isort: import 자동 정렬
3. mypy: 파이썬 타입 체크
4. flake8: 파이썬 코드 스타일 체크

이것들을 Git Hook을 이용하여 commit 전에 검사한다. import 해놓고 사용하지 않는 모듈이나 파이썬 코드 스타일에 맞지 않는 코드등을 commit 전에 검사하여 이상이 있으면 커밋하지 않는다.

이 부분도 자세하게 기록하고 싶은데, 멘토님이 설정한거라서 나는 잘 모르겠다.. 나중에 배운 후에 기록하는걸로... 기약