인증 Authentification
인증은 무엇이고 왜 할까요?
인증 Authentification
우리 서비스를 누가 쓰는지 어떻게 사용하는지 추적이 가능하도록 하기 위해 필요
- 필요한 것 : 아이디, 이메일주소, 비밀번호 등
비밀번호 관리
법규 상의 강제
무조건 암호화 해야함 (비밀번호, 바이오정보, 주민등록번호 등)
통신 시 개인정보를 주고받을 때 SSL을 적용하여 암호화 (HTTPS) : 프론트 → 백 과정에서의 암호화 + DB에 저장 시 개인정보를 해싱하여 복원할 수 없도록 함
암호화 방식
단방향 해쉬란?
해쉬함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해 쓰임. 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용함
MD5, SHA-1, SHA-256 등이 있다
→ ⛔️ 하지만 역추적으로 비밀번호를 알아낼 수 있음 : Rainbow Table
→ Salting, Key Stretching으로 조금 더 어렵게 만듦
Salting
입력한 비밀번호와 임의로 생성한 문자열(salt)을 합쳐서 해싱함, 물론 이때에 비교를 위해 해시값과 소금값을 같이 저장해야함
Key Stretching
해커가 해시값을 계산하는데에 필요한 시간을 대폭 늘리기 위해 salting, 해싱을 여러번 반복하는 것
→ 원본 값 유추하기 어렵게 만듦
⚠️ 하지만 이도 시간을 늘리는 용도일 뿐 → 사용자가 비밀번호를 주기적으로 바꾸는 것이 가장 좋음
bcrypt
Salting, Key Stretching 대표 라이브러리
DB 설계를 복잡하게 할 필요 없이 (salt 값 필드를 추가할 필요 없이) 하나로 만들어줌
인가 Authorization
해당 유저가 request에 해당하는 권한이 있는지 확인하는 절차
HTTP = Request-Response + stateless
→ 이전 로그인 값을 기억하여 그대로 사용할 수 있게 해주는 것이 인가 (ex. token)
서버는 로그인 했다는 것을 어떻게 알 수 있음?
→ headers에 메타데이터를 보내 확인 : JSON Web Token (JWT)
요청 1의 응답 1에서 200 OK와 함께 Token 발행
요청 2는 발행받은 Token과 함꼐 요청
JSON Web Token
header와 payload은 인코딩한 정보가 들어감 (암호화 X) → 개인 정보를 넣으면 안됨!
-
header : 토큰의 타입, 해시 알고리즘 정보 → BASE64 인코딩
-
payload : 만료시간, Claim → BASE64 인코딩
예) user-id에 우리 DB에 있는 PK 값을 저장 → DB에 접근할 수 없다면 그냥 빈 정보일 뿐 (개인정보 아님!) -
signature : 우리 서버에서 만든 토큰인지 매칭을 하는 부분 (암호화 되어서 서명에 저장됨) 백엔드에서 자기가 만든 토큰이라는 것을 보여주기 위하여 secret key를 이용함 → 대조하여 서로 통신
