Third-Party Auth Systems
Why delegate the responsibility?
우리는 시스템 구현과 관련된 몇 가지 위험을 탐색하고자 한다. 대부분의 위험은 우리의 server가 우리의 ground truth를 찾는 것을 시도하고 자신이라고 주장하는 사람이 맞는지 아닌지를 결정하는 back-end에 존재한다.
Monolichic 구조는 적은 endpoint, responsibilities를 갖고 있는 작은 시스템으로 시작할 때 적합하다. 하지만 시스템이 커지기 시작하면 더 많은 complexibility를 갖게 될 것이고 유지 관리가 버거워질수도 있다.
보통 많은 responsibility를 가진 monolithic service의 경우에는 당신의 코드 변경을 어렵게 만드는 상호의존성(Interdependency)이 존재할것이다. 이것을 technical debt라고 한다. 당신이 만약 변화들을 빠르고 효율적으로 만들지 못한다면 그것은 실수로 이어질수 있으며 특정 취약점으로까지 이어진다.
현대의 구조는 Microservices라고 종종 불린다. 우리는 이러한 개별적인 책임을 갖고 스택의 여러 영역에 걸쳐 구축된 소규모 서버 또는 소규모 아키텍처로 나뉜다.
당신은 하나의 서버와 하나의 responsibility를 갖고 있을 수도 있다. 예를 들어, 우리는 하나의 API server를 갖고, 하나의 calender service와 puppy directory 같은 것을 갖고 있다. 모든 시스템들은 self-contained이고 우리의 목표를 달성하기 위해서는 그들간에 최소한의 interaction이 필요하다.
만약 우리가 API server에서 변경을 만들고자 한다면 나머지 두개(Puppy directory, Calendar service)는 건드릴 필요가 없다. 하지만 우리의 Authentication service는 모든 시스템 안에 각각 들어가있으므로 만약 한 시스템 내의 authenciation service에서 변경을 만든다면 우리는 그러한 변경을 모든 다른 services에도 적용해주어야 한다. 그것은 모든 서비스들을 중단시킬지도 모른다. 게다가 하나에서 취약점이 발견되면 우리는 전체 스택에 걸쳐서 그것을 고쳐야한다.
이러한 경우에는 인증 시스템을 자체의 microservice로 취급하는 것이 좋다. 이것은 우리의 인증 서비스가 single self-contained unit으로 인증에 관련된 모든 것을 처리할 수 있도록 하는 것이다.
Front-end가 직접 auth service에 interface할 수 있고 API, puppy, calender services에 필요한 정보를 제공한다.
이제 사용자는 auth service로 요청을 생성하고 auth service에서 인증을 수행하면 front-end로 결과를 제공한다. 우리는 이제 token이라는 개념을 소개할 것이다. 이 토큰은 credential(로그인 자격증명)이 될 것이다. 이것은 임시적이며 front-end가 후속의 requests 동안에 그 사람을 기억할 수 있도록 한다.
이제 당신만의 authentication microservice를 수행하거나 제3의 authentication system을 사용할 수도 있다. 대표적으로 Auth0, AWS, Cognito, Okta, Firebase 등이 있다. 이 모든 시스템들은 해당 업무 관리, 책임 관리가 제공되는 이점 뿐만 아니라, 일반적으로 사용되는 다른 유형의 인증 메커니즘(i.e. SSO)을 즉시 추가하는 것과 같은 부가적인 이점이 있다.
