SK networks AI Camp - 인증&인가

○ Authentication(인증; 로그인)

    ● Client가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정
    ●  유저가 누구인지 확인하는 절차 e.g.) 회원가입하고 로그인하는 것.
    ●  필요한 이유 : 서비스를 사용자를 추적이 가능하도록 하기 위함, 타인에게 사용자의 정보를 보호

 

○ Authorization(인가; 권한)

    ●  권한부여, Client가 하고자 하는 작업이 해당 Client에게 허가된 작업인지를 확인
    ●  특정 자원에 대한 접근 권한 확인 절차
    ●  유저에 대한 권한 허락

 

○ 인증방식

    1. Session/Cookie 방식

        ● Cookie : 일종의 서버와 클라이언트가 대화하기 위한 수단
            - 구성 : 이름, 값, 만료 날짜, 경로 정보

            - 브라우저가 서버와 연결이 되었을 때 브라우저에서 자동적으로 쿠키를 생성, response 할 때 쿠키를 담아 전송
            - 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 전송
            - 요청 헤더의 set-cookie 속성에 정보를 담을 수 있음.
            - 쿠키에 담긴 데이터는 브라우저에서 관리
 

 

        ●  Session : 서버와 클라이언트의 연결이 활성화된 상태

            - 클라이언트가 서버와 통신 → 서버는 해당 클라이언트에 대해 세션 id 부여

            - 세션 스토리지에 세션 정보 저장 → 클라이언트는 이 세션id를 쿠키를 통해 기억
            - 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 cookie에 세션 id를 담아서 전송
            - 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태 판단
              (즉, 세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함)
            - 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리 가능
              (세션 객체가 자물쇠로 잠긴 상자라면 세션 id 가 열쇠인 셈)
            - 세션을 사용하지 않고 쿠키만으로 어떤 데이터를 주고받는다면, 클라이언트는 이미 모든 데이터를 알고 있음

 

    ● 인증순서
        - 사용자 로그인 요청
        - 서버에서 계정 정보를 읽어 사용자 확인 → 사용자의 고유한 ID 부여 → 세션 저장소에 저장 → 세션 ID 발급
        - 사용자는 서버에서 해당 세션 ID를 받아 쿠키에 저장 → 인증이 필요한 요청마다 쿠키를 헤더에 실어 전송
        - 쿠키를 받아 세션 저장소에서 대조 → 대응되는 정보를 가져옴 → 인증 완료 & 서버는 사용자에 맞는 데이터를 전송

 

  2. 토큰 기반 인증 방식(JWT; Json Web Token)

     : Session/Cookie 방식은 해커가 인증된 사용자의 Cookie를 실어 서버에 요청을 보내면 서버는 인증된 사용자인지,
       해커인지 구별할 방법이 없음. 그래서 인증에 필요한 정보를 암호화하는 방식(JWT)이 만들어짐.

      ● Token: 인증을 위해 사용되는 암호화된 문자열

           - 사용자가 인증에 성공 → 서버는 토큰을 생성 → 클라이언트로 전송
             (토큰도 세션과 마찬가지로 사용자가 보내는 요청에 포함)
           - 세션 인증에서는 서버가 세션ID를 저장, 클라이언트가 쿠키에 실어 보낸 세션 ID와 대조해서 확인하는 반면,
             토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지를 확인만
           - 세션 인증에 비해 서버 운영의 효율이 좋음

 

      ● JWT(Json Web Token) 구조
           - Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등
           - Payload : 서버에서 보낼 데이터. 일반적으로 유저의 고유 ID값, 유효기간
           - Verify Signature : Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명

 

       ● 인증순서
           - 사용자가 로그인
           - 서버 : 계정 정보를 읽어 사용자를 확인 → 사용자 고유ID값을 부여 → 기타 정보와 함께 Payload에 넣음
           - JWT의 유효기간 설정
           - 암호화할 Secret Key를 이용해 Access Token을 발급
           - 사용자는 Access Token을 받아 저장 → 인증이 필요한 요청마다 토큰을 헤더에 실어 보냄
           - 서버에서는 해당 토큰의 Verify Signature를 Secret Key로 복호화 → 조작여부, 유효기간을 확인
           - 검증이 완료 → Payload를 디코딩 → 사용자의 ID에 맞는 데이터를 가져옴

 

○ Refresh Token( Access Token과 똑같은 형태의 JWT)

      ● Access Token(JWT) 문제 : 제 3자에게 탈취당할 경우 보안에 취약
      ● 처음에 로그인을 완료 했을 때 Access Token(짧은 유효기간)과 동시에 발급되는 Refresh Token은 긴 유효기간 보유

      ● Access Token은 만료됐을 때 새로 발급해 주는 열쇠가 됨.
      ● Access Token은 탈취당하면 정보가 유출되는 건 동일 but 유효기간이 짧기 때문에 좀 더 안전

 

○ Refresh Token 인증 방식

      1.사용자가 ID, PW로 로그인 & 서버에서는 회원 DB에서 값 비교
      2. 사용자 인증 → 서버에서 Access Token, Refresh Token을 발급(보통 회원 DB에 Refresh Token을 저장)
      3. 서버 : 사용자에게 Access Token, Refresh Token을 전송
      4. 사용자 : Refresh Tokendms 은 안전한 저장소에 저장 → Access Token을 헤더에 실어 요청 전송
      5. 서버 : Access Token을 검증 후 이에 맞는 데이터를 사용자에게 전송
      6. Access Tokendl 만료 → 사용자는 만료된 Access Token을 헤더에 실어 요청
      7. 서버 : Access Token 만료 확인
      8. 만료된 토큰임을 알리고 권한 없음을 신호 전송(Access Token이 만료될때 마다 6 ~ 8 과정을 거칠 필요 X)

      9. Access Token의 Payload를 통해 유효기간을 알 수 있음 So, If API 요청 전에 토큰이 만료  바로 재발급 요청 가능
      10. 사용자 : Refresh Token과 Access Token을 함께 서버로 전송
      11. 서버 : 받은 Access Token이 조작 여부 확인, Refresh Token과 사용자의 DB에 저장되어 있던  RT를 비교
      12. 서버 : Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 사용자에게 전송
      13. 새로운 Access Token을 헤더에 실어 API 요청