[JS백엔드] 인증과 인과

유저기능

• 인증(Authentication) : 리퀘스트를 보낸 사용자가 누군인지를 파악하는 것
• 인가(Authorization) : 리퀘스트마다 할 수 있는 걸 제한하는 것

인증(Authentication)

• 인증을 하기 위해선 서버에 유저에 대한 정보가 저장돼 있어야 함 ~> 유저를 나타내는 모델을 만듦
  • 모델? 클래스와 비슷하게 특정 리소스에 대한 정보를 관리하기 편하게 코드로 표현해 놓은 것
• [회원가입 플로우]
  1. 회원가입 페이지에서 필수 정보 입력 후 [회원가입] 버튼을 누르면 클라이언트는 서버에 회원가입 URL로 유저를 만들어달라는 POST 리퀘스트를 보냄(입력된 정보는 리퀘스트 바디로 전송)
  2. 리퀘스트를 받은 서버는 인증 정보에 대한 기본적인 테스트 후 유저 데이터 새롭게 저장
     • 테스트 실패시) 에러 리스폰스를 클라이언트에 전송
     • 테스트 성공시) 성공 리스폰스를 전송
• [로그인 플로우]
  1. 로그인 정보 입력 후 [로그인] 버튼을 누르면 클라이언트는 로그인을 처리하는 서버 URL로 POST 리퀘스트를 보냄(회원가입 때처럼 인증 정보를 바디로 보냄)
  2. 리퀘스트를 받은 서버는 어떤 유저가 인증을 원하는지 찾고 PW로 인증을 요청하는 사람이 그 계정의 주인인지 확인 
     • 일치하는게 없다면) 에러 리스폰스
     • 일치한다면) 성공 리스폰스와 함께 로그인 한 유저가 누구인지 알리는 인증서를 보냄... 이것을 받은 클라이언트는 컴퓨터에 저장하고, 이후 리퀘스트를 보낼 때 붙여서 같이 보내줌(이것을 통해 서버는 누가 리퀘스트를 보냈는지 알 수 있음)

쿠키 인증: 서버에서 리스폰스의 Set-Cookie 헤더를 통해 클라이언트에 인증서를 저장하고, 리퀘스트의 Cookie 헤더를 통해 이걸 다시 서버로 보내는 인증 방식 

• 쿠키 보안
  • Secure : HTTPS에서만 클라이언트에서 서버로 쿠키가 보내짐... 항상 리퀘스트와 리스폰스가 암호화 되기 때문에 누군가 중간에 리퀘스트를 가로챘을 때 정보 유출을 줄일 수 있음
  • HttpOnly : 클라이언트가 JS코드로 해당 쿠키에 접근할 수 없게 됨 | 그냥 쿠키를 설정한 웹사이트에 리퀘스트로 보낼 수 만 있음 | 악의적으로 클라이언트가 개인정보에 직접 접근하는 것을 막을 수 있음
  • SameSite : CSRF 공격 예방 | SameSite를 Strict로 하면 다른 도메인에서 리퀘스트를 보낼 때 쿠키가 가는 걸 아예 방지

Set-Cookie: cookie_name=cookie_value; Secure;
Set-Cookie: cookie_name=cookie_value; HttpOnly;
Set-Cookie: cookie_name=cookie_value; SameSite=Lax;

 

Authorization 헤더 인증

• 장점) 리퀘스트에 인증서를 붙일지 안 붙일지 선택 가능 | 서로 다른 루트 도메인 사이 인증 가능 
• 유의할 점) PW 같이 민감 정보는 쿠키나 로컬 스토리지에 절대 저장하면 안됨 
• 서버는 리스폰스에 Set-Cookie 헤더가 아닌 바디에 인증서 추가 후 클라이언트에게 전송 → Set-Cookie가 없기에 브라우저가 자동으로 쿠키 저장 X, JS코드로 인증서 직접 저장 
• 저장된 인증서를 Authorization 헤더를 통해 서버에 보내는 방법) 리퀘스트에 Authorization 헤더 추가 후 그 뒤에 인증서를 붙여줌... 브라우저가 자동으로 해주는게 X, JS 코드 사용 → 리퀘스트를 받은 서버는 Authrization 뒤에 있는 인증서를 확인해서 누군지 식별 

세션 기반 인증

• 세션 : 서버가 저장하는 사이트 방문자들에 대한 기록

토큰 기반 인증

• 인증 토큰을 사용해서 리퀘스트를 보낸 유저 파악
  • 인증 토큰? 유저에 대한 정보를 암호화한 문자열
• 요즘은 JWT(JSON Web Token) 형식 많이 사용
• 효율성, 유연성, 무효화, RESTful API 측면에서 세션 기반 인증보다 토큰 기반 인증이 더 좋음

인코딩과 Base64URL

• 인코딩 : 데이터를 여러 곳에서 쉽고 안정적이게 사용하기 위해 통일된 형식으로 바꾸는 것 | 웹에서는 base64url 많이 사용
  • Base64 인코딩 : 데이터를 0, 1로 표현하고 이걸 6자리로 끊어서 아스키에 포함된 64 문자 중 하나로 바꿔주는 인코딩 방식
  • Base64URL 인코딩 : Base64와 거의 유사 |  +, / 문자들은 URL에 사용될 때 특정되기에 의미가 없는_, - 사용

기본 인증(Basic Authentication)

• 인증서 개념을 아예 사용하지 않고, 온전히 이메일&비밀번호만 사용하는 것
• 리퀘스트의 Authorization 헤더 사용 | 토큰 인증 시 헤더 뒤에 Basic, 그리고 이메일과 비밀번호는 : 로 이어줌
• 단점) 보안상의 이유로 요즘엔 거의 사용하지 않음

Refresh 토큰

• Access 토큰이 만료됐을 때, 이메일과 비밀번호를 사용하지 않고 access 토큰을 새롭게 발급받는데 사용되는 토큰
  • access 토큰이 더이상 리퀘스트 인증할 수 없게 되면, 클라이언트는 access 토큰을 새롭게 발급받는 URL에 새로운 GET 리퀘스트를 보냄(바디에 refresh 토큰을 함께 보냄) → 서버는 refresh 토큰이 유효한 걸 확인 후 새로운 access 토큰을 발급하고, 리스폰스로 클라이언트에 돌려줌
• 일반적으로 refresh가 access 보다 만료시간이 더 김

JWT(JSON Web Token) : JSON 형식의 데이터를 문자열로 인코딩한 토큰

• . 을 기준으로 3영역으로 나뉨
  • Header : 토큰 자체에 대한 정보가 저장
  • Payload : 토큰이 실질적으로 저장하려는 정보 | 저장하고 싶은 데이터 종류의 제한 없음 | 최대한 짧게 | 공식 이름 최대한 활용(exp, iat, jti ...)
  • Signature : 토큰을 믿을 수 있는지 확인하기 위한 데이터 저장
• 헤더와 페이로드는 단순히 인코딩 된 것 이기에 아무나 볼 수 있음 ~> 보안에 민감한 정보는 넣지 않기

인가(Authorization) : 리퀘스트가 어떤 권한이 있는지 판단

• 일반적으로 성공적인 인증이 일어나고 그 뒤에 인가가 따름 
• 인증하기 위해서 인가라는 이름의 헤더를 사용하는데, Authorization 헤더는 인가가 아닌 인증을 위한 헤더