인증

• 로그인, 회원가입(사용자임을 증명)
• 로그인에 성공하면 access token(암호화된 유저정보를 포함 - JSON WEB TOKEN(JWT)을 클라이언트에게 전송하고, 다음 번부터는 토큰을 확인하여 자동로그인 가능
• 비밀번호는 반드시 암호화하여 저장 (단방향 해쉬함수가 일반적으로 사용됨)
  : 단방향 해시 함수는 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성
  : 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어서 단방향성(one-way) 이라고 함
  : backend로 가기도 전에 HTTPS를 통해(SSL을 사용) 암호화 됨
  : 다만, 너무 오래 사용되다보니 Rainbow table attack (미리 해쉬값들을 계산해 놓은 테이블을 Rainbow table이라고 한다.)을 활용해서 어느정도 알아낼 수 있는 방법이 생겨남
  : 그래서, 취약점을 극복하기 위해서 2가지 방법이 사용됨

  Salting
  : 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산하는 방법.
  Key Stretching
  : 단방향 해쉬값을 계산 한 후 그 해쉬값을 또 또 해쉬 하고, 또 이를 반복하는 것을 말한다.

: Salting과 Key Stretching을 구현한 해쉬 함수 중 가장 널리 사용되는 것이 bcrypt(언어별로 존재하는 라이브러리의 일종)임. bcrypt는 처음부터 비밀번호를 단방향 암호화 하기 위해 만들이전 해쉬함수임

왜 ID & PW가 아니라,acess token을 이용하는가?

• Performance 측면
  No heavy bcrypt call, just a simple hash
• Client-side storage 측면
  No actual ID and password stored in the client such as cookie.
  Also, token is very server specific - not reused in any other site.
  <access Token예시>

HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"}

인가

• 사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정
• Authroization도 JWT를 통해서 구현 될 수 있음
• access token을 통해 해당 유저 정보를 얻을 수 있음으로 해당 유저가 가지고 있는 권한(permission)도 확인 할 수 있음