[TIL] 인증 & 인가

인증

개념

• Authentication은 유저의 identification을 확인하는 절차.
• 쉽게 설명하면, 유저의 아이디와 비번을 확인하는 절차.
• 인증을 하기 위해선 먼저 유저의 아이디와 비번을 생성할 수 있는 기능이 필요.

로그인 절차

1. 유저 아이디와 비번 생성
2. 유저 비번 암호화 해서 DB에 저장.
3. 유저 로그인 -> 아이디와 비밀번호 입력.
4. 유저가 입력한 비밀번호 암호화 한 후 암호화되서 DB에 저장된 유저 비밀번호와 비교.
5. 일치하면 로그인 성공.
6. 로그인 성공하면 'ACCESS TOKEN'을 클라이언트에게 전송.
7. ACCESS TOKEN이란, 유저가 그 이후 매번 로그인 하지 않아도 되도록 인정해주는 TICKET.
그래서 다른 페이지도 돌아다닐 수 있다.

단방향 해쉬 함수(one-way hash function)

• 유저의 비밀번호는 절대 비밀번호 그대로 DB에 저장하지 않는다.
• 유저의 비밀번호는 꼭 암호화 해서 저장 해야 한다.
• 비밀번호 암호에는 단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰인다.
  (ex. 가령 test password를 hash256이란 해쉬 함수를 사용하면
  0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e 값이 나온다.)
  

Bcrypt

• 단방향 해쉬 함수도 몇가지 취약점이 있다. 대표적으로 Rainbow table Attack(미리 해쉬값들을 계산해놓은 테이블을 통해서 해킹하는 방식을 Rainbow Table Attack이라고 한다)

• 그래서 단방향 해쉬 함수의 취약점들을 보완하기 위해 2가지 방식을 사용한다.

Salting

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

Key Stretching

• 단방향 해쉬값을 계산한 후 그 해쉬값을 또 해쉬하고 또 해쉬하고.. 이를 반복하는 것을 말한다.

• 암호화를 여러 번 반복하기 때문에, 확실히 보안성을 높일 수 있다.
  

• Salting과 Key Stretching을 구현한 해쉬 함수 중 가장 널리 사용되는 것이 BCrypt이다.
  Bcrypt는 처음부터 비밀번호를 단방향 암호화 하기 위해 만든 해쉬함수다.

• bcrypt는 Hash결과 값에 Salt값과 Hash값 및 반복횟수를 같이 보관하므로 DB설계를 복잡하게 하지 않는다.
  BCrypt를 통해 해싱된 결과 값의 구조는 아래와 같다.
  
  

JWT(JSON Web Tokens)

• JWT의 구조
  

1) 헤더에는 토큰의 타입과 Hash 알고리즘 정보가 들어간다.

2) 헤더의 내용은 BASE64방식으로 인코딩해 JWT의 가장 첫 부분에 기록된다.

3) 내용(payload)에는 exp와 같이 만료시간을 나타내는 공개 클레임 클라이언트와 서버간 의하에 사용하는 비공개 클레임 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소로 위치한다.

4) 서명은 JWT가 원본그대로라는 것을 확인 할때 사용하는 부분이다. BASE64URL 인코드 된 header와 payload 그리고 JWT secret을 헤더에 지정된 암호 알고리즘으로 암호화 하여 전송하며 프론트 엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인한다.

인가

개념

• Authoriztion은 유저가 요청하는 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) 혹은 다른 에러 코드를 보낸다.