인증(Authentication)

• 유저의 identificaiton을 확인하는 절차 (유저의 아이디와 비번을 확인하는 절차)

로그인 절차

1. 유저 아이디&비번 생성
2. 유저 비번 암호화 해서 DB에 저장
3. 유저 로그인 -> 아이디& 비번 입력
4. 유저가 입력한 비밀번호 암호화 한후 DB에 저장된 암호화된 유저 비번과 비교
5. 일치하면 로그인 성공
6. 로그인 성공하면 access token을 클라이언트에게 전송
7. 유저는 로그인 성공후 다음부터는 access token을 첨부해서 request를 서버에 전송함으로서 매번 로그인 해도 되지 않도록 함

비빌번호 암호화

• 유저 비밀번호는 DB에 저장될 때 암호화되기 때문에 내부 개발자들 조차 볼 수 없다.

• 비밀번호 암호에는 단방향 해쉬 함수(one-day has function)가 일반적으로 쓰인다.

  • 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성한다. 원본 메시지를 알면 암호화된 메시지를 구하기 쉽지만 암호화된 메시지로 원본 메시지를 구할 수 없어서 단방향성(one-way)이라고 한다.
  • 예시)basf3qfasefdsfafafâfae00aje0ja0djf0aj0ejf90aj039a023842934579ad

Bcrypt

• 단방향 해쉬 함수의 취약점
  • 해쉬 함수는 원래 패스워드를 저장하기 위해 설계된 것이 아닌 짧은 시간에 데이터를 검색하기 위해 설계된 것.
  • 이러한 속성을 이용해 해커들은 임의이ㅡ 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교하여 패스워드를 추측한다.
• 일반적인 2가지 보완점
  Salting과 Key Stretching을 구현한 해쉬 함수중 가장 널리 사용되는 것이 bcrypt.
  • Salting
    실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산하는 방법.
  • Key Stretching
    단방향 해쉬값을 계산 한 후 그 해쉬값을 또 또 해쉬 하고, 또 이를 반복하는 것을 말함.

JWT(JSON Web Tokens)

• 유저한 로그인 성공한 후에 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.
  

• 서버에서는 access token을 복호화 해스 해당 유저 정보를 얻게 된다.
  아래와 같이 유저 아이디를 통해 해당 유저가 누군지 알 수 있다.

• 그리고 해당 유저는 매번 로그인 해도 되지 않도록 한다.
  (예: 회원가입 후에 재로그인 하지 않고 바로 로그인)

구조

HEADER.PAYLOAD.SIGNATURE
세 부분을 점(.)으로 구분하는 구조다.

Header

• JWT를 검증하는데 필요한 정보를 가진 JSON객체는 Base64 URL-Safe 인코딩된 문자열.
• JWT를 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다.
• 하나는 서명 시 사용하는 알고리즘, 다른 하나는 서명 시 사용하는 키(Public/Private Key)를 실벽하는 값이다.

Payload

• JWT의 내용.
• 페이로드이 있는 속성들을 클레임 셋(Claim Set)이라 부름
• 클레임 셋은 JWT에 대한 내용(토큰 생성자 정보, 생성 일시 등)이나 클라이언트와 서버간에 주고 받기로 한 값들로 구성됨.

Signature

• 점(.)을 구분자로 해서 헤더와 페이로드를 ㅍ합친 문자열을 서명한 값.
• 토큰이 변조되지 않았음을 증명하는 데 사용되는데, 이 때 SECRET KEY가 필요.

access token 생성방법

• 가장 널리 사용되는 기술은 JWT(JSON Web Token)이다.
• 말 그대로 유저 정보를 담은 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것.

Access Token > ID and Password

• 간단한 hash를 사용하기 때문에 bcrypt call이 가볍고 빠르다.
• 클라이언트 측 cookie에 비번과 아이디를 저장하지 않아도 된다.
• token은 해당 서버에만 사용가능하며 다른 사이트에서 재사용 불가능하다.

인가(Authorization)

• 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차.
  (예: 해당 유저는 고객 정보를 볼 수 있지만 수정할 수 없다)
• Authorization도 JWT를 통해서 구현 가능
  • access token을 통해 해당 유저 정보를 얻을 수 있음으로 해당 유저가 가지고 있는 권한(permission)도 확인할 수 있다.

Authorization 절차

1. Authentication 절차를 통해 access token을 생성.
   (access token에 유저 정보를 확인할 수 있는 정보가 들어있어야 한다. 예: user id)
2. 유저가 request를 보낼 때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인한다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
   7 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.