인증(Authentication)
- 유저의 아이디와 비번을 확인하는 절차
- 인증을 하기 위해선 먼저 유저의 아이디와 비번을 생성할 수 있는 기능도 필요
* 로그인 절차
- 유저 아이디와 비번 생성
- 유저 비번을 암호화 해서 DB에 저장
- 유저 로그인 -> 아이디와 비밀번호 입력
- 유저가 입력한 비밀번호와 암호화해서 DB에 저장된 비밀번호와 비교
- 일치하면 로그인 성공
- 로그인 성공하면 access tokend을 유저에게 전송
- 유저는 로그인 성공후 다음부터 access token을 첨부해서 request를 서버에 전송함으로 매번 로그인해도 되지 않도록 함
* 유저 비밀번호 암호화
- 유저의 비밀번호는 절대 비밀번호 그대로 DB에 저장 X
- DB가 해킹을 당하면 유저의 비밀번호도 그대로 노출됨
- 외부 해킹이 아니더라도 내부 개발자나 인력이 유저들의 비밀번호를 볼 수 있음
- 유저의 비밀번호는 꼭 암호화해서 저장!!
- DB가 해킹을 당해도 비밀번호가 그대로 노출되지 않음
- 내부 인력도 비밀번호를 알 수 가 없음
- 암호화에는 단방향 해쉬 함수가 일반적으로 쓰임
Bcrypt
-
단방향 해쉬 함수도 몇가지 취약점이 있음
- 해쉬 함수는 원래 짧은시간에 데이터를 검색하기 위해 설계된거라 맘 먹고 추적하면 빠른시간에 원래 비밀번호를 찾아낼 수 있다. 또 한번 해쉬되면 값이 바뀌지 않는 단점이 있다.
-
bycrypt의 취약점을 보완하는 2가지 보완점
- salting : 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해쉬값을 계산하는 방법
- key stretching : 단방향 해쉬값을 계산한 후 그 해쉬값을 또 또 해쉬하고, 또 이를 반복하는 것
JWT(Json Web Token)
- 회원 로그인이 완료 되었을 때 발행되는 토큰
- jwt에는 암호화된 회원정보다 들어있고, 복호화를 통해 사이트내의 서비스를 사용할 수 있는지 확인(인가)하는데 사용
- aaa.bbb.ccc의 형태로 구성
- aaa는 header(헤더) 부분으로 타입(JWT)과 알고리즘(BASE64같은 것)을 담는다.
- bbb는 payload(내용) 부분으로 보통 유저정보(id같은)와 만료기간이 객체형으로 담긴다.
- ccc는 signature(서명) 부분으로 header, payload를 인코딩 한 값을 합친 뒤 SECRET_KEY로 해쉬한다.
인가(Authorization)
- 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차
- 예를 들어 유저는 고객 정보를 볼 수 있는 있지만 수정 할 수는 없다 등.
인가 절차
- 인증 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 함 (예를 들어 user id).
- 유저가 request를 보낼때 access token을 첨부해서 보냄
- 서버에서는 유저가 보낸 access token을 복호화. 복호화된 데이터를 통해 user id를 얻음
- user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인
- 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리.
유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보냄
