인증(Authentication)/인가(Authorization)란 무엇인가
- 인증이란 ?
: 유저가 누구인지 확인하는 절차, 회원가입하고 로그인하는 것 - 인가란?
: 유저에 대한 권한을 허락하는 것 - 인증 & 인가 왜 필요할까?
- 우리 서비스를 누가, 언제, 어떻게 쓰고 있는가를 파악(추적)하기 위해
- 인증에 필요한 것은?
- 아이디, 이메일 주소, 비밀번호 등이 있다.
- 인증과 인가는 API에서 가장 자주 구현되는 기능중 하나
- Private한 API는 물론이고 Public한 API도 기본적인 인증과 인가를 요구
1. 인증(Authentication)✌️
- 인증은 유저의 identification을 확인하는 절차이다
- 쉽게 설명하면 유저의 아이디와 비번을 확인하는 절차
- 인증을 하기 위해서 먼저 유저의 아이디와 비번을 생성할 수 있는 기능도 필요하다
2. 비밀번호 암호화는 어떻게 이루어지는가 👁
-
유저의 비밀번호는 절대 비밀번호 그대로 DB에 저장하지 않음
- DB가 해킹 당하면 유저의 비밀번호도 그대로 노출될 뿐더러 내부 개발자나 인력이 그 정보를 볼 수있음 -> 유저의 비밀번호는 꼭 암호화해서 저장👤
-
비밀번호 암호화에는 단방향 해쉬 함수(one-way-hash function)가 일반적으로 쓰임
ref) 단방향 해쉬함수란?
: 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성
원본 메세지를 알면 암호화된 메시지 알 수 있지만 그 반대는 안됨 그래서 one-way이다.
3. Bcrypt 😎
- Salting & Key Streching 대표적 라이브러리
- brypt는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리이다.
단방향 해시함수의 취약점(Rainbow table attack)
-
해시함수는 원래 패스워드를 저장하기 위한 것이 아닌 짧은 시간에 데이터를 검색하기 위해 설계된 것
그렇기 때문에 해시 함수는 본래 처리 속도가 최대한 빠르도록 설계된 속성을 이용해서
공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트릴 비교 가능 -
이런 방식으로 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않음
ref) Rainbow table
: 미리 해쉬값들을 계산해 놓은 테이블
단방향 해시함수의 보완점(Salting,Key Stretching)
Salting
- 원본 값에 '소금을 뿌리듯이' random값을 추가하는 것
Key Stretching
- 연산을 느리게 하기 위해 해쉬값이 구해지면 그 해시값을 기반으로 또 해쉬를 하고 해쉬를 하고 n번 해서 최종값을 저장 => rainbow attack이 어려워짐
두 가자 암호 알고리즘으로 기존 단방향 해쉬함수의 단점을 보완
4. 인가(Authorization)🤷
- 사용자가 로그인하면, 해당 사용자가 맞는지 확인하는 절차
JSON WEB TOKEN(JWT)를 쓰면 인가가 수월함(서버가 유저 정보를 갖고 있으므로 데이터에서 유저의 권한 정보도 읽어들이면 됨)access token을 통해 해당 유저 정보를 얻을 수 있으므로 해당 유저가 가지고 있는 권한(permission)도 확인가능
JSON WEB TOKEN(JWT)
Header - Payload -Signature로 구성되어 있다.- Header에는 토큰 타입과 해시 알고리즘 정보가 들어간다.
- Payload 에는 토큰 정보 또한 직접적인 정보가 아닌 primary key 정보가 들어가서 쉽게 알수없는 정보를 넘기는 게 아니라, 쉽게 식별할 수 없는 키를 넘겨준다. 토큰의 유효 기간을 넘겨주는것도 일반적이다.
- Signature에는 앞에 정보를 암호화 한 내용이 들어간다고 볼 수 있다.
- JSON Weg Token을 frontend는 받아서 다시 backend로 넘겨 주어야함
Authorization 절차
- Authentication 절차를 통해
access token을 생성한다. access token에는 유저 정보 를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id). - 유저가 request를 보낼때
access token을 첨부해서 보낸다. - 서버에서는 유저가 보낸
access token을 복호화 한다. - 복호화된 데이터를 통해 user id를 얻는다.
- user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
- 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
- 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보 낸다.
