(TIL15) 인증/인가

인증 & 인가

• 인증, 인가는 API에서 가장 자주 구현되는 기능 중 하나
• Private, Public API를 가리지 않고 기본적인 인증, 인가는 요구됨

인증

유저의 identification을 확인하는 절차

• 쉽게 유저의 아이디와 비밀번호를 확인하는 절차를 생각하면 좋으며, 특히 비밀번호가 중요
• 즉, 누가 서비스를 이용하고 있으며, 어떻게 사용하는 지 추적하는 데 필요

로그인 절차

1. 유저 아이디, 비밀번호 생성
2. 비밀번호 암호화 후 데이터베이스 저장
3. 유저 로그인 시 아이디, 비밀번호 입력
4. 유저가 입력한 비밀번호를 암호화 한 후 데이터베이스에 지정된 유저 비밀번호와 비교
5. 일치하면 로그인이 실행되며 access token을 클라이언트에 전송

비밀번호는 어떻게 관리해야 할까?

유저의 비밀번호를 그대로 데이터베이스에 저장하게 되면 해킹 시 그대로 노출될 뿐만 아니라 내부 인력이 확인할 수도 있음

• 법규 상 비밀번호, 주민등록번호와 같은 주요 개인정보는 암호화 등의 보안 절차를 통해 전송되어야만 함

• 국가에서 권고하는 상용 암호화 알고리즘을 통해 개인정보를 암호화 하며, 데이터베이스 저장 시에는 개인정보를 해싱하여 복원할 수 없도록 조치

• 통신 시 개인정보를 주고받을 때 SSL을 적용하여 암호화(HTTPS)

암호화

• 비밀번호 암호화에는 단방향 해쉬함수(MD5, SHA-1, SHA-256)가 일반적으로 사용

  • 본래 해쉬함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크 등을 위해 사용되지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로도 사용

  • 단방향 해쉬함수는 원본 메시지를 변환하여 암호화된 메시지(다이제스트(digest))를 생성

    • 원본 메시지를 알면 암호화된 메시지를 구하기 쉬우나 암호화된 메시지로는 원본 메시지를 구할 수 없어 단방향성이라고 칭함

  • 그러나, 해쉬 함수는 본래 목적 상 처리 속도가 최대한 빠르도록 설계되어 해커가 이에 접근 했을 경우 빠르게 해킹할 다이제스트를 비교하여 해킹할 수 있음

    • 또한, 같은 문자열을 동일한 알고리즘으로 해싱했을 경우, 동일한 다이제스트가 출력되기 때문에 이렇게 미리 계산된 해쉬값들을 Rainbow Table이라고 함

• 단방향 해쉬함수의 취약점을 보완하기 위해 Salting과 Key Stretcing이라는 개념이 도입

Salting

• 실제 비밀번호 이외에 추가적인 랜덤 데이터를 더해 해시값을 계산하는 방법

Key Stretching

• 단방향 해쉬값을 계산하고 그 해쉬값을 반복적으로 해쉬하여 값을 도출

bcrypt

• Salting과 Key Stretching을 구현한 해쉬함수 중 가장 널리 사용되는 함수로, 처음부터 비밀번호를 단방향 암호화하기 위해 만들어진 해쉬함수 라이브러리

인가

• 사용자가 서버에 로그인하면 해당 사용자가 맞는지 확인하는 절차로써 유저 본인이 요청하는 요청을 실행할 수 있는 권한이 있는 유저인지를 확인하는 절차
• 이 때 응답 시 headers에 메타데이터(JSON Web Token)을 보내서 확인

JWT(JSON Web Token)

• JWT는 헤더, 페이로드, 시그니쳐로 구성

• Header

  • 토큰의 타입, 해시알고리즘 정보 삽입
  • 헤더의 내용은 BASE64방식으로 인코딩하여 가장 첫 부분에 기록

• Payload

  • 클라이언트와 서버간 협의하에 사용하는 비공개 클레임과 만료 시간을 나타내는 공개 클레임이 사입

  • 두 요소를 조합하여 BASE64 방식으로 인코딩 후 두 번째 요소에 기록

• Signature

  • JWT가 원본 그대로라는 것을 확인할 때 사용

  • BASE64 방식으로 인코드 된 헤더와 페이로드 그리고 JWT secret(별도 생성)을 헤더에서 지정한 암호 알고리즘으로 암호화 하여 전송

인가 절차

1. 인증 절차를 통해 access token 생성(유저 정보를 확인할 수 있는 정보가 있어야 함)
2. 유저가 request를 보낼 때 access token을 첨부해서 보냄
3. 서버에서 access token을 복호화
4. 복호화된 데이터를 통해 user_id 등을 얻음
5. user_id를 통해 db에서 해당 유저의 권한 확인
6. 유저가 충분한 권한을 가지고 있으면 해당 요청 처리
7. 유저가 권한이 없으면 Unauthorized Response(401) 코드 등을 전송