[영상후기][10분 테코톡] 🎡토니의 인증과 인가

인증 : (식별가능한 정보로) 서비스에 등록된 유저의 신원을 입증하는 과정

인가 : 인증된 사용자에 대한 자원 접근 권한 확인

웹에서의 인증과 인가

• 자원을 적절한/유효한 사용자에게 전달/공개 하기 위한 방법
• 회원가입 -> 로그인 : 인증
• 권한 획득 : 인가

HTTP : 무상태성

인증의 방식

1. Request Header 활용 : HTTP 요청 헤더에 실어서 보냄

• URL에 아이디, 비밀번호 실어서 보내기(API가 구현되어 있다면)
  -> 브라우저가 Base64 인코딩 후 요청 헤더에 넣어서 보냄
  -> 서버에서 DB체킹 후 로그인
  -> 사용자가 매번 로그인을 해야하는 하는 문제(해결하고자 브라우저 스토리지 힘을 빌리기)

2. Browser 활용하기 : 저장공간 활용(쿠키 활용)
   -> 사용자 ID/PW를 쿠키에 저장해두고, 사용자가 인증이 필요한 요청을 할 때마다 같이 서버에 요청
   -> 편리한 방법, 해커입장에서도 편리(low한 정보(암호화x), 클라이언트가 서버보다 보안 취약)
   -> 보안을 향상하기 위한 서버에 도움 요청(세션 활용)
   
3. 세션 활용

• 인증된 사용자의 식별자 + 랜덤 문자열(Sesstion Id)
• 응답의 헤더로 넘겨줌
• 클라이언트 저장
• 보안 향상
  1. 사용자의 low한 정보x(암호화o), 정보를 가지고 가더라도 큰 위험이 없음
  2. 세션의 만료기간을 정할 수 있음 -> 해커가 가져가더라도 만료가 되면 유효하지 않음
  3. 세션의 관리를 서버 -> 탈취 시 세션 자체를 삭제
  • 문제점 : 로드밸런스를 진행할 때, 요청한 요청이 세션을 발급한 서버로 가지 않은 경우 인증이 안됨
    • 세션을 각 서버에서 관리해서 문제
    • 세션 스토리지를 도입하여 해결(서버에서 관리하는 세션들을 모아두는 곳)
    • 사용자가 많아지면 세션 스토리지 터지는 문제 발생
      (HTTP 무상태성 <-> 상태성을 가져서 생기는 문제)

4. 토큰 활용 : 정보의 요청과 응답 안에 사용자의 상태를 담아서 처리하는 방법

• JWT(JSON WEB TOKEN)

  • 시크릿 키를 사용하여 키 생성
  • 시크릿 키를 사용하여 인증 진행
    • JWT 자체는 해독하기 쉬워서 민감한 정보(비밀번호 등)를 담지 않음
    • 시크릿키를 노출되면 JWT토큰 자체도 끝 -> 시크릿 키를 서버 내부에서 잘 관리해야 함

  4-1. 활용하기

• 시크릿키를 활용하여 토큰 생성 -> 헤더에 넣어서 응답 보냄

• 서버 유효성 검사 : 본인이 가진 시크릿 키로 진행

• 유효하다면 사용자 정보 파악(이름, 만료시기, 권한, 비밀번호(x))

  • 장점 : 로드밸런스에서 넘어가는 요청을 각 서버에서 가지고 있는 시크릿 키로 인증
    • 확장성 연결 : 사용자가 많아져도 서버 각자 해석이 가능(별도 서버 없이도 가능)
  • 단점 : 엑세스토큰 탈취당하면 해커는 사용자와 똑같은 역할을 할 수 있음
    • 만료기한을 정해두는 방식으로 해결(하지만 일반 사용자도 불편)

refresh token 개념 등장(Access Token, Refresh Token 생성 -> Access Token 서버에 저장x)

• 두가지 모두 응답으로 보내서 클라이언트 저장
  • client는 Access Token 활용해서 요청을 보냄 -> 만료되면 브라우저가 Access Token과 Refresh Token을 같이 보냄 -> 서버는 돌아온 Refresh Token 참고하여 DB를 찔러 맞다면 갱신한 Access Token을 클라이언트에 보냄

토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다.

• DB접속을 통해 사용자 검증 안해서 장점
• 토큰 관리를 해야한다(결국 토큰도 탈취당할 수 있다)

• 은행 : 보안이 중요한 은행은 Access 토큰의 만료기간을 짧게 잡음
• 일반적 : 편리성을 위해 길게 잡는 등