토큰 발급 프로세스 개선

[Philip Kim (Jaewon Kim)]

보안에 대한 생각

현재 구현된 상태에서 보면, oAuth 액세스 토큰 발급 프로세스가 클라이언트와 자원서버(google, naver, ... 등) 간에 직접적으로 이뤄지고 있습니다.
따라서 보안문제가 발생하지 않을까 처음에 생각했으나, 결론적으로는 보안 문제는 없어보입니다. 다만 서버와 클라이언트 간의 의존방식이 조금 불필요하게 복잡 해진다는 느낌이 듭니다. (마치 모듈 간 의존 설계처럼)

우선 보안문제 관련해서 처음에 이런게 있지 않을까 했던 부분들은 다음과 같습니다.

첫번째, API_KEY가 클라이언트에 직접 삽입 되면서, 탈취하여 어뷰징 할 수 있다는 점입니다.
(디버깅을 편히 하기위해 로컬호스트를 허용한 상태)

물론 해결할 수 있습니다. (oAuth 제공자들이 그렇게 허술하지 않다)
oAuth 설정에서 host와 IP를 제한함으로써 해당 API_KEY를 이용해서 발생하는 요청 자체를 막을 수 있을 것으로 예상됩니다.

하지만 결국 액세스 토큰이 클라이언트로 들어오게 된다는 것이고, 네트워크 레벨에서 패킷을 탈취하여 이를 통해 사용자 개인정보들에 마음대로 접근할 수 있는 위험이 추가로 발생하게 됩니다.

물론 이것도 https를 이용해서 해결할 수 있습니다. 실제로 oAuth 실배포 레벨에서 이런 이유로 ssl 인증을 강요하는 것 같습니다.

결론은 보안문제는 없어 보입니다.
만약 있다면, ssl 인증(암호화 알고리즘) 자체의 기술적인 결함

구조에 대한 생각

문제가 있고 개선해야할 부분은 구조적인 부분이라 생각하는데, 우선 현재 구현은 passport로 되어있습니다.

passport를 사용하는 것 자체는 상관이 없는데 지금 인증에 대한 부분만 graphql과 다른 엔드포인트를 제공하고 있습니다. 따라서, 서버측은 그냥 엔드 포인트만 나누면 되는 편한 작업이지만, 클라이언트 측에서는 또 react-google-login 같은 모듈을 사용해서, 리액트 라이프사이클과 엮여 액세스 토큰을 받아오고, 이를 바탕으로 서버에서 새로운 서비스 자체 토큰을 rest api로 발급받고, 이를 apollo로 또 상태관리를 진행하니까 스파게티 구조처럼 되어가고 있는 것으로 보입니다.

(충분히 직접 개발한다면 일괄적인 프로세스로 관리할 수 있어 보이며, 인증이라는 것이 파이프라인 처럼 모든 프로세스의 앞단에 위치하는 작업이다 보니 구조화 할 필요성이 있다고 생각)

따라서 가능하면, passport를 제거하고, 제거하지 않더라도 apollo 상에서 일괄적으로 처리하는 프로세스로 만들어야 한다고 생각합니다.