인증(Authentication) & 인가(Authorization)
- API에서 가장 자주 구현되는 기능 중 하나로 private한 API는 물론이고 public한 API도 기본적인 인증과 인가를 요구한다.
인증
- 유저의 identification을 확인하는 절차
- 로그인 절차
1.유저 아이디와 비번 생성
2.유저 비번 암호화 해서 DB에 저장.
3.유저 로그인 -> 아이디와 비밀번호 입력
4.유저가 입력한 비밀번호 암호화 한후 암호화되서 DB에 저정된 유저 비밀번호와 비교.
5.일치하면 로그인 성공
6.로그인 성공하면 access token을 클라이언트에게 전송.
7.유저는 로그인 성공후 다음부터는 access token을 첨부해서 request를 서버에 전송함으로서 매번 로그인 해도 되지 않도록 한다.
비밀번호는 어떻게 관리해야 할까?
- 유저의 비밀번호는 DB가 해킹을 당하면 유저의 비밀번호도 그대로 노출되기 때문에 절대 그대로 저장하지 않고 암호화 해야한다.
- Database에 저장시 개인정보를 해싱하여 복월할 수 없도록 한다.
- 통신시 개인정보를 주고 받을 떄 SSL을 적용하여 암호화 한다.(HTTPS)
그렇다면 암호화는 어떻게 할까?
- 비밀번호 암호화에는 단방향 해쉬 함수를 사용하며 해시화하면 난수화된 특정 문자열을 리턴한다.
- 단방향 해쉬 함수는 원본 메세지를 변환하여 암호화된 메세지인 digest를 생성한다. 원본 메세지를 알면 암호화된 메세지를 구하기는 쉽지만 암호화된 메세지로는 원본 메세지를 구할 수 없어서 단방향성(one-way)이라고 한다.
- (MD5, SHA-1)(둘은 보안취약), SHA-256등이 있다.
Bcrypt
- 단방향 해쉬 함수도 취약점이 있는데 그 중 하나가 미리 해쉬값들을 계산해 놓은 데이블을 이용하는 Rainbow table attack이다.
- Rainbow table: 같은 알고리즘으로 해싱하면 항상 같은 결과가 도출되므로 가능한 경우의 수를 모두 해시값으로 만든다.
- 해쉬함수는 원래 패스워드를 저장하기 위해 설계된 것이 아닌 짧은 시간에 데이터를 검색하기 위해 설계된 것이기 때문에 공격자는 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다.
- 단방향 해쉬 함수의 취약점들을 보완하기위해 salting과 key stretching을 이용한다.
- salting: 입력한 비밀번호와 임의로 생성한 문자열(salt)를 합쳐 해상해서 이 해시값을 저장한다.(비교를 위해 해시값과 salt값을 같이 저장해야 한다.)
- key stretching: salting 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것(단방향 해쉬값을 계산한 후 그 해쉬값을 또 해쉬하는 것을 반복하는 것을 말한다. 최근에는 일반적인 장비로 1초에 50억개 이상의 다이제스트를 비교할 수 있지만 ekey stretching을 적용하여 동일한 장비에서 1초에 5번만 비교할 수 있게 한다. )
- salting과 key stretching을 구현한 해쉬 함수 중 가장 널리 사용되는 것이 bcrypt이다.
- Bcrypt는 해쉬 결과값에 소금값과 해시값 및 반복 횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB 설계를 복잡하게 할 필요 없다.
- Bcrypt를 통해 해싱된 결과 값(Digest)의 구조
인가(Authorization)
- 사용자가 서버에 로그인하면 해당 사용자가 맞는지 확인하는 과정
- HTTP의 특징인 request/response, stateless한 성질때문에 서버는 사용자가 로그인 했을 경우 header에 메타데이터를 보내서 확인하는데, 이 메타정보를 JWT라고 한다.
JWT(Json Web Token)
- 유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
}- 그 후 서버에서는 access token을 복호화(디코딩)해서 해당 유저의 정보를 얻게된다.
{
user_id = 1
}- 복호화해서 얻은 유저 아이디를 통해 해당 유저가 누군지 알 수 있고 해당 유저가 매번 로그인 해도 되지 않도록 한다.
- access token을 생성하는 방법중 가장 널리 사용되는 기술 중 하나가 JWT이다.
- JWT는 유저 정보를 담은 JSON 데이터를 암호화해서 클라이언트와 서버간에 주고 받는 것이다.
JWT의 구조
header
- 토큰 타입과 해시 알고리즘 정보가 들어간다.
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록된다.
{“alg”: “HS256”, “typ”: “JWT”}payload
- exp와 같이 만료 시간을 나타내는 공개 클레임, 클라이언트와 서버간 협의하에 사용하는 비공개 클레임 두가지 요소를 조합하여 작성한 뒤 BASE64 인코딩하여 두번째 요소로 위치한다.
{ “user-id” : 1, “exp”: 1539517391 }signature
- JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분이다.
- BASE64URL 인코드된 header와 payload, 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송한다.(복호화 가능)
- 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에는 전송받은 JWT의 서명 부분을 복호화하여 서버에 생성한 JWT가 맞는지 확인한다.(계약서의 위변조를 막기 위해 서로 사인하는 것과 비슷하다.)
- 주의점은 header와 payload는 암호화가 아닌 BASE64인코딩 한 것이므로 누구나 원본을 볼 수 있으니 개인정보를 담지 말아야 한다.
Authorization 절차
- Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
- 유저가 request를 보낼때 access token을 첨부해서 보낸다.
- 서버에서는 유저가 보낸 access token을 복호화 한다.
- 복호화된 데이터를 통해 user id를 얻는다.
- user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
- 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
- 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.
