인증(Authentication) & 인가(Authorization)

API에서 자주 구현되는 기능 중 하나

인증

유저의 신원(아이디와 비밀번호)을 확인하는 절차
인증을 위해서는 앞서 유저의 아이디와 비번을 생성할 수 있는 기능이 필요

로그인 절차

1. 유저 아이디와 비번 생성
2. 비번을 암호화해서 DB에 저장
3. 로그인을 위해 아이디와 비번을 입력하면
4. 비번을 암호화한 후 DB에 저장된 비번과 비교
5. 로그인 성공하면 access token을 클라이언트에게 전송
6. 로그인 후에는 access token이 첨부된 request를 서버에 전송

유저 비밀번호 암호화

1. 유저의 비번은 꼭 암호화하여 저장 - 해킹에 대비 / 내부 인력들의 misuse 대비
2. 비번 암호화에는 단방향 해쉬 함수가 일반적으로 쓰인다.

• 단방향 해시 함수
  : 원본 메시지를 변환해 암호화된 메시지(다이제스트(digest))를 생성
  • 단방향성 : if know 원본 메시지 => can get 암호화된 메시지
    with 암호화된 메시지 only => cannot get 원본 메시지

단방향 해쉬 함수

• 단방향 해쉬 함수의 취약점
  • 해시 함수의 태생은 패스워드 저장이 아니라 짧은 시간에 데이터를 검색하기 위해 설계된 것
  • 이러한 속성때문에 해커는 매우 빠른 속도로 임의의 문자열과 해킹할 대상을 비교할 수 있다. 그러므로 패스워드가 복잡하지 않을 경우 짧은 시간 내에 해킹이 가능하다.
• 보완점 2가지
  • Salting : 실제 비번에 추가적으로 랜덤 데이터를 더해 해시 값을 계산
  • Key Stretching : 해쉬값을 반복적으로 해쉬하고 동일한 장비에서 1초에 5번 정도만 비교할 수 있게 제한.
• Salting과 Key stretching을 쉽게 사용하기 위해 사용하는 라이브러리 : Bcrypt

JWT (JSON Web Tokens)

• Access token을 생성하는 방법 중 가장 널리 사용되는 기술 : JWT!

  • access token이란 유저의 로그인 정보를 암호화해 request에 첨부하면 서버는 access token을 복호화해서 해당 유저 정보를 얻는다.

ID와 비번 대신에 Access Token을 사용하는 이유 :

• 비교적 무거운 Bcrypt 대신 간단한 해쉬 사용
• client-side storage

인가 (Authorization)

request를 요청하는 유저가 권한이 있는 유저인지 확인하는 절차
header에 메타데이터를 보내서 확인함

구조

aaaaa.bbbbbbb.cccccccc

a: header
b: payload (내용) - 만료시간을 정할 수 있음 : 핵심내용이 포함됨
c: signature - 내가 발행한 키가 맞는지 확인할 수 있는 부분 : 서명은 복호화가 가능해야 함

인가 절차

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