백엔드 인증처리 (Node.js)

인증처리와 관련해서 크게 3가지를 소개하고자 한다.

 

목차

1. 구현한 인증처리 소개

2. 권한 인증(Authentication)

3. 권한 인가(Authorization)

4. 토큰 사용

5. 화면 권한 제어

6. 인증&인가 처리 로직

7. 마무리

 

---

1. 구현한 인증처리 소개

 

Node.js 인증처리를 router 접근 전 middleware에서 일괄적으로 인증처리 로직을 타도록 설정했다.

 

 

기존 방식이나 일반적인 예제 방식을 보면, 인증처리를 router 함수에서 middleware를 별도로 추가하여 인증처리를 했다. 대부분 예제들이 그랬다. 나는 이 방식이 마음에 안들었다. 그 이유는 크게 2가지가 있다. 첫 번째, 모든 API에 대해서 1개씩 인증처리 절차를 추가해야했기 때문이다. 두 번째, 현재 인증처리 로직이 적용된 API는 어떤 것이 있는지 한 눈에 살펴보기 어려웠다.

 

장점

 - API 로직을 한 눈에 관리하기 좋다. 예를 들어, quiz01 router에 있는 API들을 확인하고자 할때, search 기능을 활용한다면 관련 API를 모두 한 눈에 확인할 수 있다.

 - Authentication과 Authorization 한 번에 확인할 수 있기에, API를 관리하기 쉽다. (흐뭇하다)

단점

 - 물론 단점은 있겠지만, 굳이 기존 방식인 router 함수의 middleware에서 처리하는 로직과 비교하면 시간이 더 필요하다는 것이다. 왜냐하면, 이렇게 관리하는 페이지를 별도로 만들어주어야 하기 때문이다. (사실 큰 단점은 아닌거 같다. 가급적이면 만드는게 좋은거 같다.)

 

---

2. 권한 인증(Authentication)

 - 크게 3가지 규칙을 세웠다. 이게 맞는지는 모르겠다. 나는 맞는거 같지만?...

API URL에 대한 3가지 규칙이 있다.

1. 요청이 들어온 API에 대해서 일치하는 API RULE이 있는지 확인해서 있으면 처리한다.

2. 요청이 들어온 API에 대한 규칙이 없다면, 대규모 범주에 해당하는 API RULE이 존재하는지 확인한다. (이게 잘한 짓인지는 잘 모르겠네... 없어도 될거 같다. 아마 조만간 없어질 예정)

    예시) 요청 '/api/quiz01/quiz-safasf-qwrqw' 이 들어왔을 때, 1번 규칙에 따라서 일치하는 규칙이 존재하는지 확인한다. 이에 대한 규칙이 없을 경우, '/api/quiz01'에 대한 규칙이 존재하는지 확인한다. 여기서 '/api/quiz01'에 대한 규칙이 있는지 확인하는게 2번 규칙이다. API 규칙이 존재한다면 해당 규칙에 맞게끔 처리한다.

3. 그 외, 모든 요청은 차단한다.

 

지금 보니 권한인증과 관련해서 2번에 대한 부분은 굳이 없어도 되겠다는 생각이 든다. 내가 저 규칙 2번을 만든 이유는 admin 기능에 대해서 일괄적으로 권한 설정을 해주고 싶었기 때문이다. 그런데 굳이 그럴 필요없이 하나씩 설정하는게 맞다는 생각이 든다. 왜냐하면, 관리자와 개발자 권한이 또 나뉘기 때문이다.

 

그리고 '권한인증'에 대해서 조금 더 나아간다면 관리자를 세분화 할 수도 있다. 예를 들어, 네이버 카페 같은 경우에는 특정 카테고리를 관리할 수 있는 권한(permission)을 별도로 받을 수 있다. (role을 부여 받는게 아니다.)  서비스를 이제 시작하는 프로그램 같은 경우에는 이러한 permission 부분까지 고려할 필요가 없을거 같다. 그저 사용자 role만 고려했다.

---

3. 권한 인가(Authorization)

* 일치하는 권한 인증을 헸다면?

1. '누구나'로 체크되어 있다면, 더 이상 인증절차를 거치지 않고 해당 요청을 정상적으로 처리한다.

2. 요청한 사용자 권한으로 사용할 수 있다고 체크되어 있다면, 해당 요청을 정상적으로 처리한다.

 

 

사실 권한인증과 권한인가는 동시에 같이 발생한다. 왜냐하면, 권한인증과 권한인가는 한개의 컬렉션에서 동시에 관리하고 있다. 마치 위에 그림에서 본 API 관련 테이블처럼 말이다. 그저 권한을 조회할 때 한번에 조회하면 될 뿐이다. 하지만 이론 상으로는 권한인증과 권한인가는 분리해서 바라보는게 맞아서 이렇게 목차를 따로 뺐다.

---

4. 토큰 사용

 

토큰 vs 세션

 - 당장 내가 서버 1대로 운영하겠지만, 확장성(scale up)을 고려하면 토큰 방식이 좋을거 같았다. 기존 회사에서는 세션 방식으로 서비스를 운영했는데, 토큰이라는 새로운 방식으로도 개발을 해보고 싶었다. 세션과 토큰을 공부하면 할 수록, 확장성을 고려한 요즘 서비스들에 있어서 토큰 방식이 너무 매력적이었다. 무엇보다도 더 중요한 사실은 B2C 서비스 기업들도 대부분 토큰 방식을 채택해서 사용하고 있다. 굳이 세션을 선택해야할 이유는 없었다.

 - 토큰 방식을 활용할 때, 'access token', 'refresh token'을 함께 활용한 방식을 채택했다. 일단 처음에는 access token만으로 구현했는데, 사용자가 불편할거 같았다. 그리고 보안적으로는 안전하기를 바랬다. 그래서 refresh token을 발급하기로 마음 먹었다.

 - 토큰은 로그인 시, 새롭게 발급한다. 로그아웃 시, 토큰을 제거한다. 만약에 토큰 기한이 만료되면 새롭게 로그인하여 토큰을 발급 받아야 한다. 

 

---

5. 화면 권한 제어

나는 특정 화면에 접근 시, 해당 화면에 대한 권한이 있는지 확인하도록 했다. 예를 들어, 관리자 화면에 접근 시 권한 있는 사람만 접속할 수 있다. 당장에는 접근 제어 유무를 제어할 수 있는 컴포넌트를 제작 및 테스트를 완료했다. 해당 기능은 아직 대부분 화면에 적용하지 않았다. 추후 운영서버 오픈 전에 일괄적으로 검토하며 적용할 예정이다. 적용 방법도 쉽다. (내 기준에서는 쉽다.)

 

아래 코드처럼 Auth 함수를 통해서 인증처리를 구현한다. 뒤에 따라붙는 첫 번째 boolean 값이 유저 접근 가능 유무, 두 번째 boolean 값이 관리자 접근 가능 유무이다. 

 

현재까지 대다수 컴포넌트에 대해서 화면 접근 권한을 주지 않았지만, 필요한 화면에 따라서 그때그때마다 금방 줄 수 있는 상황이다.

---

6. 인증&인가 처리 로직

 

현재까지 내가 구현한 인증처리 로직 결과물을 보면 이렇다.

 

화면(접근 가능 유무 확인) -> API 미들웨어 (인증&인가 여부 확인) -> API 기능 접근

 

화면 접근에 대한 인증처리와 API 미들웨어에서의 인증&인가 여부 확인에 대해서는 설명했다. 하지만, 간혹 API 기능 접근에서도 인증&인가 정보를 확인하기도 한다. 왜냐하면, 유저만 별도로 추가적인 값을 던져주기도 한다. 예를 들어, 내 프로그램 '개발자 지름길' 기능들 중에서 '퀴즈 풀기' 기능이 대표적이다. 

회원들은 퀴즈 풀 경우, 퀴즈 설정이 저장되고 풀었던 문제들이 전부 저장된다. 회원이 아닌 사용자도 퀴즈를 풀 수 있기를 바랬다. 단, 회원이 아니라면 퀴즈 설정이 저장되지 않고 풀었던 퀴즈들 역시도 저장되지 않도록 했다. 이것이 내가 말한 'API 기능'에서 처리하는 인증&인가 여부에 대해서 확인한다는 의미다.

---

7. 마무리

'권한 인증'과 '권한 인가'에 대한 부분을 boiler-plate로 분리해서 활용한다면, 내가 추후에 다른 서비스를 개발하더라도 현재 만든 기능을 적절하게 보완 해나갈 수 있을 것으로 예상된다. 인증처리와 관련된 소스가 추후에 업데이트 될 수도 있을 것을 고려하여 유연성이 좋은 소스코드로 변경할 필요가 있겠다.

 

나는 이러한 결과물을 내기까지 꽤나 시간이 걸렸다. 왜냐하면, 계속 가설을 세우고 기능을 만들고 테스트를 했다. 그러면서 계속 가설을 세우고 코드를 수정했다가 고쳤다가를 계속 반복하면서 나온 결과물이었다. 인증처리 부분은 사용자가 보기에는 당연한 부분이며, 관심 가질 이유가 없는 부분이다. 하지만, 개발자로써 이런 부분을 직접 구현한 것에 있어서 뿌듯함은 정말로 음... 머랄까... 여튼 기분이 너무 좋다.

 

곧 인증처리에 대한 기능을 업데이트 할 예정이다. 보안에 대한 부분을 강화하기 위해서다. 그 방법으로 생각해 둔 것은 secure cookie, SSL 적용하여 HTTPS 프로토콜 활용하는 것 등이 있다.

 

아마 다음에 인증처리와 관련하여 조금 더 업데이트를 하게 된다면 아래 참고 링크를 몇 번 더 보게 될거 같다. 다른 자료들도 많이 찾아보고 했지만, 아래 글만큼 괜찮은 글을 찾기는 어려웠다. 혹시 인증처리와 관련되어 공부하고 싶고, 구현을 하고 싶은 분이라면 아래 글을 꼭 읽어보는 것을 추천한다. 그 이유는 우선 기본 인증처리 방법에 대해서 설명하면서 단점을 이야기하고, 보완 방법, 단점, 보완 방법에 대해서 끊임없이 꼬리물기를 하면서 인증처리에 대한 개념을 뇌 속에 때려박아 주는 글이었다.

 

읽어주셔서 감사합니다. 기분이 좋네요.

혹시 이상한 부분 발견한다면 아낌없이 피드백 부탁 드립니다. 실력 향상에 큰 도움이 됩니다.

 

참고 : 

https://bcho.tistory.com/955(이 글 정말 좋네요... 본 받고 싶음.)