목차

• 배운 내용 정리
  • 인증
    • 세션 기반 인증 방식
    • 토큰 기반 인증 방식
  • jwt
    • jwt 구조
    • jwt 장점
    • jwt 단점
    • jwt를 이용한 인증 과정
  • Django의 Permission
• 후기

배운 내용 정리

인증

1. DB에 회원의 정보를 저장한다
2. 비밀번호와 같은 입력값으로 본인이 맞는지 검증한다

1. 입력한 아이디가 DB에 있는지 확인한다
2. 없을 경우 입력한 아이디와 비밀번호로 사용자 정보를 생성한다
3. 생성한 정보를 DB에 저장한다

1. 입력한 아이디와 비밀번호를 DB에 저장된 정보와 비교한다
2. 일치하면 인증 성공
   1. HTTP 200 OK
3. 일치하지 않으면 인증 실패
   1. HTTP 401 Unauthorized
   2. HTTP 403 Forbidden

1. 비밀번호를 안전하게 저장하기
2. 클라이언트 요청 시 사용자 정보를 안전하게 담아 전달하기
3. 로그인 이후, 매번 아이디와 비밀번호를 담아 요청하지 않고도 사용자의 신원이 검증된 요청임을 알 수 있도록 하기

세션 기반 인증 방식

• 클라이언트가 가지고 있는 건 세션 ID뿐
  • 세션 ID에는 사용자 정보가 담겨있지 않아서 세션 ID가 노출되어도 사용자 정보 노출 안됨
• 서버는 세션을 메모리 혹은 데이터베이스에 저장하는데, 로그인한 사용자가 늘어나면 부하가 일어난다
• 또한 서버를 확장할 때 세션 분산 시스템을 설계해야 하기 때문에 서비스 규모를 확장하기 어려워진다

토큰 기반 인증 방식

• 세션 저장소가 필요 없어진다
• 서버의 확장성이 높아지고 대량의 트래픽에도 대처 가능하다
• 토큰에 모든 정보들이 들어가 있어 데이터 누출에 취약하다

jwt

• 웹서버가 사용자의 상태 정보를 기억하고 있다가 유용한 정보로 활용한다.
• 서버에서 클라이언트세션을 유지할 필요가 없을때 서버 리소스를 절약하는 장점이 있다.

• 무상태
  • 서버 클라이언트 구조에서 서버가 클라이언트의 상태를 가지고 있지 않는다.
  • 통신이 끝나면 더 이상 상태를 유지하지 않는다.
• 장점
  • 서버의 확장성이 높다.
  • 대량의 트래픽이 발생해도 대처할 수 있다.
• 단점
  • 페이지를 이동할때마다 이전의 로그인이 유효하지 않아서 매번 로그인을 다시 해야한다.
  • 이 창 다시 열지 않기 를 눌러도 계속 팝업이 뜬다.
  • state-ful 방식보다 비교적 많은 양의 데이터가 반복적으로 전송되기 때문에 네트워크 성능저하가 될 수 있다.
  • 데이터 노출로 인한 보안적인 문제. ⇒ 이를 보완하기 위해 데이터를 압축/암호화 하기 위하여 jwt를 사용

jwt 구조

• 헤더 : 토큰의 타입과 서명(Signature)에 사용되는 암호화 알고리즘에 대한 정보를 담고 있다.
• 인증에 필요한 사용자 정보나 데이터 속성을 포함하는 부분이다. 클레임이라는 <name>:<value> 형태의 정보 단위로 구성되어 있다.
• 서명 : base64로 인코딩된 헤더와 페이로드, 그리고 비밀키를 이용하여 암호화된 값이다.
  • 헤더나 페이로드의 변조 여부를 확인하여 무결성을 검증하고 보장하는 데 사용된다. 쉽게 말하면, 공격자가 페이로드의 내용을 악의적으로 바꾸었을 때 서명을 확인하면 토큰의 유효성을 판단할 수 있다.

jwt 장점

• 데이터의 위변조를 방지한다.
• JWT는 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다.
• 세션(Stateful)과 다르게 서버는 무상태(StateLess)가 된다.
• 확장성이 우수하다.
• OAuth의 경우 소셜 계정을 통해서 다른 웹서비스에 로그인 할 수 있다.

jwt 단점

• base64인코딩을 통한 정보전달→ 전달량 많음 → 네트워크 전달시 많은 데이터량으로 부하 가능성
• payload는 암호화 되어있지 않다 ⇒ 민감한 정보 저장 X
• 토큰이 탈취당하면 만료될때까지 대처 불가능

jwt를 이용한 인증 과정

1. 클라이언트에서 사용자가 로그인하기 위해 입력한 ID와 PW를 서버에 보낸다.
2. 서버는 ID와 PW를 회원 DB에서 확인한다.
3. 회원 정보가 존재하면 JWT를 생성하여 클라이언트에 응답한다. 이때 Access Token과 Refresh Token을 같이 전달한다.
4. 이후 클라이언트는 요청할 때마다 HTTP 헤더에 Access Token을 담아 보낸다.
5. 서버는 Access Token을 검증힌다.
   1. 헤더에 담긴 토큰을 복호화해보면 이 사용자가 누구인지 확인할 수 있다.
6. 검증이 완료되면 응답을 보낸다.

1. 서버가 데이터와 함께 온 Access Token이 만료되었음을 확인한다.
2. 서버는 클라이언트에 Access Token이 만료되었음을 알려주는 응답을 보낸다.
3. 클라이언트가 Access Token과 Refresh Token을 같이 담아 재발급 요청을 보낸다.
4. 서버는 Refresh Token을 확인한 후 Access Token을 재발급한다.
5. 서버는 클라이언트에 재발급한 Access Token과 함께 응답을 보낸다.

Django의 Permission

# ../permissions.py
from rest_framework.permissions import BasePermission
 
class IsOwner(BasePermission):
      """게시물 작성자만 접근 가능하게 하기"""
    def has_object_permission(self, request, view, obj):
          if request.user.is_authenticated:
              if request.user == obj.user:
                  return True
            return False
        else:
              return False

@api_view(['POST', 'GET'])
@permission_classes([IsOwner])
def index(request):
      pass

후기