UART는 내가 실무에서 관리했던 서비스들의 서비스 중심 모니터링 시스템인 “현천”의 Single Sign On 서비스를 위한 인증/인가 관리체계이자 사용자/권한관리 플랫폼이다. 원래는 Ruby on Rails 기반으로 만들었던 SiSO가 실전에서 그 역할을 담당하고 있었으나 조금 다른 각도에서 기능을 보완하려던 중, 아예 Go 언어로 새롭게 작성해버렸다. 이 글에서는 UART를 개발하게 된 배경과 용도, 그리고 기능에 대하여 간략하게 소개한다.

인증, 중앙인증서비스

유사한 또는 동일한 사용자 집단에게 여러 서비스를 함께 제공하는 경우, 사용자 관리, 그룹 및 권한 관리, 인증/인가 관리 등을 하나의 체계 안에 통합하게 되면 여러 면에서 이득을 얻을 수 있다. 예를 들어, 업무 서비스를 개발하는 과정에서 이에 대한 고민을 줄일 수 있다는 점, 개별적으로 구현할 경우 발생할 수 있는 품질 불균형 문제의 해결, 그리고 서비스 간 사용자 정보의 동기화가 단순해지는 점 등이 그러한 부분이다. 인증/인가 관리를 통한 보안성 확보는 서비스 제공자의 업무적 입장에서도 매우 중요한 부분이며, 업무나 다루는 데이터의 성격에 따라 법적인 책임으로 이어질 수도 있다. 이러한 관점에서 인증과 관련된 기능을 한 곳에 모아 관리하게 되면 상대적으로 효과적인 인증체계에 대한 보안 관리가 가능할 것이다.

이렇게, 다양한 서비스에서 인증 및 인증의 기반이 되는 사용자 관리 등의 기능을 통합하여 다른 서비스가 그것을 활용할 수 있도록 하나의 서비스로써 제공되는 경우, 그것을 Central Authentication Service, 중앙인증서비스라 부른다.

Cloud Computing, As a Service 대잔치

특히, 근래의 IT 서비스 인프라와 플랫폼 영역은 클라우드컴퓨팅을 중심으로 빠르게 진화하고 있다. 이와 함께 Application 영역에서도 자연스럽게 새로운 접근방식의 등장 또는 기존의 접근방법을 클라우드 시대에 맞춰 변형하거나 구체화한 경우가 나타나고 있는데, 예를 들어, 근래에 핫!한 주제 중 하나인 Microservice Architecture1, MSA를 기반으로 서비스를 설계/구현하는 경우라든지, API as a Service2 개념을 활용한 독립적인 API 서비스를 만들어 다른 서비스들에게 기능 서비스를 제공하거나, 이미 제공중인 서비스의 일부 기능을 API 서비스화하여 새로운 형태의 소비자층을 만들어내는 경우, 그리고 모바일앱의 서버측 기능을 Backend as a Service3 개념으로 구현하고자 할 때, 단순한 인증체계의 통합 뿐만 아니라 (사람과 상호작용하는 인증처리가 아닌) 기계적인 인증방식에 대한 요구도 생기게 되는데, 이것을 다시 Authentication as a Service4로 받아 치는 것이 너무 자연스럽다. (실제로, Auth0 같은, Authentication을 전문적으로 서비스하는 회사도 생겨나고 있으며, 대부분의 클라우드컴퓨팅 서비스 제공자들도 나름의 관리형 인증서비스를 제공하고 있다.)

UART, 개요

개인 프로젝트로 진행 중인 서비스 모니터링 플랫폼 현천의 개발 과정에서, 앞서 설명한 인증/보안 관리의 단일화를 위해 만들었던 프로젝트가 Ruby on Rails 기반의 SiSO였다. 이미 개발한지 몇 년이 지난 지금에 와서 다시 그것을 꺼내 사용하려다 보니 몇가지 기능개선이 필요해졌는데, 아예 다시 만들어버리고 싶다는 생각이 들어서 그 개념을 살려 Go 언어로 다시 작성한 것이 UART다.

지금은 현천 프로젝트를 활발히 진행할 수 있는 상태가 아니라서 얼마나 더 개선이 가능할지, 언제쯤 범용적으로 쓸만한 물건을 만들 수 있을지는 모르겠다.

아무튼, 뭔가 거창하고 길게 소개한 UART를 간단하게 정리하면 이런 거다.

UART는 독립적 인증제공자가 아니다

  • UART는 독자적인 사용자 정보관리를 하지 않으며, 다른 OAuth2 제공자들 즉, Google, Facebook, Github 등을 통해 로그인을 해야하는 OAuth2 Client이다.
  • 일단 사용자가 UART에 로그인하게 되면, 이제 UART를 OAuth2 Provider로 활용하여 2차 인증을 제공받을 수 있다. 그래서, 업무용 앱에서 UART만 지원하게 되면, 어떤 소셜 계정으로 UART에 로그인했든, UART를 통해 다시 실제 업무를 수행할 서비스에 접근할 수 있다.
  • UART는 서비스별 역할관리, Mail 등을 이용한 메시징 등의 확장된 사용자 정보와 부가기능을 Client 앱에게 제공한다.
뭐냐, 복잡하다. 쉽게 말해라!
일단 소셜로그인으로 UART에 로그인하면, 확장된 기능과 정보를 갖는 UART를 통해 다른 서비스를 사용할 수 있는 2단계 구조다. (일종의 인증 Hub)

2단계의, Wrapper형 인증을 제공한다

  • 사용자가 자신이 원하는 소셜계정을 연동하여 쉽게 인증처리를 할 수 있는 소셜인증의 편리함과 함께,
  • 일반적인 소셜 인증에서는 관리할 수 없는 추가 정보, 즉 역할이나 조직 정보, 경보발송을 위한 메시징 시스템 등의 추가 정보와 기능을 통합관리할 수 있는 기반이 되어, 폐쇄적 사용자군에 대한 관리체계를 상대적으로 쉽고 편리하게 구성할 수 있다.
뭐냐, 왜 그렇게 한단 말이냐!
목표 시스템이 어느 정도 폐쇄성을 갖고 있으나, 조직 외부의 인원(협력회사 직원?)이 접속해야 할 필요가 있을 때, 단지 사내인증과의 통합으로 해결할 수 없고 뭔가 복잡한 인증 방식이 필요하더라.

간단하지가 않구나… 말로 설명하려니 참 어려워서, 그림으로 한 번 그려봤다. 일반적인 소셜인증을 사용하는 앱은 아래 그림과 같이 동작한다.

왼쪽에 표시된 사람모양이 사용자 인증을 제공하는 소셜 서비스이고, 오른쪽의 세 개는 각각 독자적인 소셜인증을 사용하는 서비스들이다. 이들은 서로 독립적 서비스지만, 모두 소셜인증을 사용한다는 공통점을 가지고 있다. 그리고 각각은 자신의 고유의 데이터를 담고 있는 사용자 DB를 독자적으로 갖춰야 대부분의 경우, 정상적인 서비스를 제공할 수 있을 것이다.

이와는 다르게, UART를 사용하는 구조는 아래 그림과 같이 그려볼 수 있다.

역시, 원천 인증을 제공하는 소셜 서비스와 세 개의 업무용 서비스는 동일한 위치에 있다. 그러나 그 사이의 푸른 배경에 쌓인 부분. 즉, UART가 위치한다는 점이 다른 부분이다. 또한, 개별 서비스 옆에 붙어있던 사용자 DB가 사라지고 UART로 통합된 것을 볼 수 있다. UART는, 그림에서 느낄 수 있듯이, 앞서 봤던 그림에 대입해보면 소셜인증을 소비하는 하나의 Client 앱처럼 동작한다. 다만, 나머지 세 개의 앱은 이 UART를 유일하게 인증제공자의 위상에 두고 있는 것이다. 이로써, 서로 사용자 정보를 공유하는 동일한 서비스군 내의 개별 서비스들은 UART를 통해 보다 간소화된 방식으로 인증과 사용자 정보 서비스를 받게 된다.

이렇게, UART는 OAuth2 Client 이면서 동시에 OAuth2 Provider이다.

OAuth2 Client 이면서 OAuth2 Provider

UART는 Google, Facebook, Github 등의 OAuth2 방식의 인증서비스를 제공하는 외부 인증서비스를 통하여 인증을 처리한다. OAuth2 구성 상에서 보면, OAuth2 Client 위상에서 동작한다는 뜻이다. 이렇게 Client로 동작하기 때문에, UART는 자체적으로 사용자의 비밀번호를 저장하지도 않으며, 비밀번호 변경 프로세스나 그것을 잊었을 때 재설정하는 프로세스 등을 가지고 있지 않다.

반면에, UART는 이것을 인증서버로 설정한 Client들에 대하여 OAuth2 Provider 위상에서 동작한다. UART는 그 서비스 제공 범위 안에 있는 서비스들에 대해 확장된 정보와 함께 인증서비스를 제공하게 되며, 이것을 활용하여 인증을 받는 서비스들은 UART를 통한 OAuth2 인증과 함께 UART가 추가로 제공하는 메시징 서비스 등의 부가서비스를 이용할 수 있다. (향후, 필요성이 커지면 Email 기반의 가입과 인증을 추가할 예정인데, 이 때에는 Mail을 통한 OTP(One-Time-Password) 방식을 활용하여 보안성을 강화하면서, 여전히 암호저장은 피하는 체계를 유지하려고 한다.)

현재버전에서 시스템에 접속하게 되면, 아래와 같이 세 종류의 소셜 인증을 제공하는 로그인 페이지를 보게 된다.

추가 정보의 관리

OAuth2 방식으로 업무서비스가 인증서비스로부터 인증을 받게 되면, 사용자가 허용한 정보를 받아볼 수 있게 된다. 이 때, UART는 내부적으로 확장된 체계를 이용하여 사용자의 역할 정보를 추가로 전달하게 된다. 이 추가정보는 OAuth2 규격 안에 있는 것이기 때문에 프로코콜 상에서는 전혀 색다른 것이 아니다. 다만, 일반적인 소셜 인증제공자는 이러한 정보를 가질 이유가 없으며, 있다고 하더라도 이 서비스군에서 유효한 정보가 아니기 때문에, 또는 연결동하는 것이 복잡할 수 있기 때문에 확장 정보체계를 이용하는 것이다.

OAuth2의 인증체계에 대해서는 따로 게시한 바 있는 OAuth2와 JWT, 웹기반 SSO 인증을 참고하면 도움이 될 것 같다. UART가 추가로 제공하는 정보의 관리와 개별 서비스가 받아보는 형태에 대해서는 이 글의 남은 부분에서 소개한다.

추가 기능의 제공

특정 서비스군을 위한 전용의 인증시스템이 있을 때 얻을 수 있는 장점 중 하나는, 표준 인증제공자가 제공하지 않는 특별한 기능을 함께 제공하는 것이다. 그 중 현재버전의 UART에 포함된 기능은 메시징 기능이다.

사용자를 갖는 서비스에서 사용자의 인증과 함께 많이 사용되는, 또는 필요로 하는 기능 중 하나는 사용자가 직접 확인하기 전에 뭔가 시스템이 능동적으로 알려야 할 필요가 있을 때 사용자에게 메시지를 전달하는 기능이다. 특히, 내가 목표로 하는 서비스 모니터링 서비스의 경우, 서비스 장애 등의 문제가 발생했을 때 지체없이, 그리고 확실하게 사용자에게 알리는 것이 매우 중요하다.

이러한 요건이 단일 서비스에 대해서만 구현이 되는 경우라면 큰 문제가 없지만 Microservice 구조를 갖는 다양한 서비스가 각각의 영역을 전담하여 상황을 감지하고 경보를 발생하여야 한다면 이 경보/메시징 기능을 통합하는 것이 보다 효과적일 수 있다. 이를 위하여, 통합된 경보시스템을 별도로 기획하였다가 사용자 인증시스템과 통합하는 것도 좋을 것 같아 UART에 해당 기능을 붙이는 것으로 하였다.

UART의 기능요소, 구조와 관리자 관점에서

UART에서 제공하는 추가정보와 부가기능을 정리하면 아래 그림과 같다.

UART는, 사용자에 대한 기본정보와 인증기능의 제공 외에, 이를 뒷받힘하기 위한 업무서비스(Client Application)의 관리, 개별 서비스에 대한 독립적 역할관리, 그리고 비기능적 그룹인 팀관리 등의 부가정보를 제공하며, 이와 함께 부수기능으로 인스턴트 메시징 기능을 제공한다.

‘U’ 사용자 관리

UART는 인증 시 소셜 제공자로부터 Email주소 등의 사용자 기본정보를 받아 관리하며, 이와 함께 사용자가 UART를 통해 접속하는 애플리케이션 별로 각 서비스로부터 허가받은 역할 등의 부가정보를 함께 관리한다.

위의 그림과 같이, 등록된 사용자는 이름과 메일정보 등을 소셜제공자로부터 받아 관리하게 되며, 관리자에 의해 활성상태(Active)가 되기 전에는 비활성 상태를 유지하게 되어 “가입은 자유롭게 하되 활성화는 통제”하는 체계로 되어있다.

이렇게, 내부적인 권한관리를 할 수 있기 때문에 소셜 인증은 단순한 인증을 대신할 뿐, 인가에 대한 부분은 UART에서 자체적으로 처리할 수 있다. UART 자체도 일종의 UART Client App으로 처리되며, 사용자의 상태나 권한에 따라서 기능 중 일부는 제한을 받을 수 있다.

아래의 그림은, 제한된 페이지에 접근했을 때 사용자에게 표시되는 메시지이다.

‘A’ 애플리케이션 등록 및 관리

앞서 설명한 바와 같이, UART는 인증제공자이며, 실제의 개별 업무는 각각의 업무를 처리하는 업무서비스에 의해 수행된다. 이러한 업무서비스가 UART를 통하여 인증서비스를 받기 위해서는 그 앱을 Client App으로 등록해야 한다. (이러한 OAuth2 구조 상의 역할은 OAuth2와 JWT, 웹기반 SSO 인증에서 확인할 수 있으니 참고하시라)

UART의 App 메뉴는, 이렇게 UART를 사용하고자 하는 앱을 등록하고 관리하는 곳이다.

위의 그림과 같이, 관리자 권한을 갖는 Tony Stark는 UART 자체를 포함하여 UART에 등록된 모든 응용서비스의 등록정보를 확인할 수 있다.

서비스군에 다양한 서비스가 등록된다면 각 서비스는 서로 다른 조직 또는 관리자에 의해 관리되는 경우가 일반적이라고 할 수 있다. 이런 경우, 각 단위 서비스는 각각의 서비스 책임자가 등록 및 관리를 하게 된다. UART에 이러한 앱 관리자 권한을 가진 사용자가 로그인하게 되면, 자신이 관리하는 앱만을 보게 된다. 아래는 Black Widow라는, 앱 관리자 권한을 가진 사용자가 동일한 메뉴에 접속했을 때의 화면이다.

또한, 앱 관리자 권한을 가진 사용자는 새로운 앱을 등록할 수 있는데, 아래와 같이 앱의 이름, 앱을 식별하기 위한 코드, 간단한 설명과 앱이 서비스되는 URL, 그리고 마지막으로 UART를 통해 인증을 할 때 사용할 OAuth2 Callback URL을 등록해주게 된다. Icon 항목은 선택적으로 사용할 수 있는데, 해당 앱을 표시할 때 사용하는 이미지이다.

앱 목록에서 앱을 선택해주면 앱의 자세한 사항을 확인할 수도 있다. 아래와 같이, 앱 등록 시 입력했던 일반사항과 자동으로 생성되는 OAuth2 인증 시 사용하기 위한 App Key, App Secret 등이 표시되며, 이 서비스에서 사용할 역할에 대한 정보와 각 역할에 대한 요청 현황을 확인할 수 있다.

위의 앱상세 화면에는 각 역할에 대한 활성사용자 수와 요청 현황 등을 표시해 준다. 그러나, 각 사용자에 대한 상세 정보는 표시하지 않는데, 이러한 상세 내용은 각 앱의 특성에 따라 자체적으로 관리할 부분이며, UART의 기능 범위는 단지 인증/인가를 위한 수준의 기능을 제공하는 것으로 그 범위가 한정지어 있다. 이를 통하여, UART의 역할/권한이 과도하게 증가하는 것을 피하고 꼭 필요한 기능을 제공하는 것에 집중하게 된다.

‘R’ 역할관리

서비스의 권한관리를 위해서는, 사용자와 인증 다음으로 인가의 개념이 필요하다. 인증이란, 접속한 사용자가 정상적인 사용자인지 확인하는 개념, 신분증이나 기타 인증 수단으로 자신이 맞다는 것을 확인하는 개념이며, 인가란 그 사용자가 적절한 권한을 갖고 있는지를 업무 관점에서 확인하는 개념이다. 이러한 권한 관리를 보다 쉽게 하기 위한 개념이 역할인데, 역할을 사용하여 사용자를 구분함으로써, 우리는 개별 사용자에게 권한관리를 하는 부담을 줄이고 특정 권한을 갖는 역할그룹에 사용자를 추가함으로써 쉽게 권한관리를 할 수 있는 것이다.

거의 모든 서비스는 관리자와 사용자의 구분이 있을 것이다. UART는 기본으로 admin이라는 코드를 갖는 관리자 역할과 user라는 코드를 갖는 사용자 역할을 기본으로 등록하게 되며, 이 두 역할은 수정이나 삭제가 불가능하다. 이 외에, 해당 서비스의 특성에 따른 다양한 역할이 필요할 수 있는데, 앱의 관리자는 위의 상세화면에서 “New Role” 버튼을 이용하여 추가해줄 수 있다.

위의 그림에서는, lead라는 코드와 Team Lead라는 이름을 갖는 추가 역할을 서비스에 추가하는 화면이다. 이렇게 역할을 추가해주고 사용자가 이 역할을 요청하여 권한을 획득하면, 사용자가 서비스에 접속할 때, 서비스는 그 사용자의 역할 정보를 함께 확인할 수 있다.

‘T’ 팀 또는 그룹

역할과는 다른 관점에서, 사용자의 신분을 권한 또는 기능적인 것과는 무관하게 묶어 관리해야 할 필요가 가끔 있다. 기능적으로 같은 권한을 갖지만 성격이 다른 사용자의 구분이 필요한 경우가 발생한다는 뜻이다. 이런 경우를 위해, 조직을 관리할 필요가 발생하는데, 이러한 조직 구분을 위하여 Team 기능을 고려하고 있다. (필요성이 크지는 않아서 아직 구현하지 않은 부분)

‘T’ 기본 메시징

이 메시징 기능은 일반적인 인증/인가시스템의 구성요소는 아니다. 그래서 원래는 별도의 시스템으로 개발할 계획이었는데, 어떤 면에서는 메시징과 인증인가를 구분하게 될 때, 단순하게 풀기 어려운 상호 의존성이 발생하기도 하여 전체적인 서비스 구조와 설치가 복잡해질 수 있고, 어떤 면에서는 오히려 과도한 구분일 수 있겠다는 생각이 들었다.

그래서, 단순한 수준의 메시징을 UART에 녹여 지원하고, 만약 이보다 더 복잡하거나 세부적인 메시징 시스템이 필요하게 된다면 (예를 들어 메시징 허브 수준의 것이 필요하거나 지능형 발송기능이 필요하거나) 그 때 다시 고민하기로 했다.

일단, 다음 화면을 보면, UART에서 발생하는 다양한 메시지가 관리자에게 전달된 상태를 확인할 수 있다.

대충 눈에 띄는 것을 보면, 사용자가 권한을 넘어 어디엔가 접속했을 때, 접속 원한 위반을 관리자에게 알려주는 “access violation” 메시지, 새로운 사용자가 등록되었음을 알리는 “New Member Registered” 메시지, 새 앱이 등록되었을 때 발생하는 “App… created” 등의 메시지가 그런 것이다. 목록에서 문서 모양의 아이콘으로 표시된 메시지는 단순 로그성 메시지이며, 편지 모양의 아이콘이 표시된 메시지는 메일로 실시간 발생된 메시지이다.

또한, 권한이 다른 사용자에게는 그 권한에 맞는 메시지가 가게 되는데,

앱 관리자 권한을 갖는 Black Widow에게는 “role … requested by…” 같은 앱에 관련된 메시지가 전달된다. 그 중 하나를 자세히 보면 아래와 같다.

위의 메시지는 새로운 역할요청이 사용자로부터 발생하였을 때 해당 앱의 관리자가 받게 되는 메시지인데, 발송자, 앱, 구분 등의 일반정보와 함께 메일 등으로 전달되었을 메시지의 본문이 그대로 함께 표시된다.

UART의 기능, 사용자 입장에서

UART가 인증을 대신해주는 시스템이다 보니, 사용자 입장에서는 그것의 존재가 그렇게 크게 들어나지 않는다. 아래 부분은 아주 기본적인, 그리고 새로운 사용자가 짧은 시간 동안 사용하게 될 사용자 환경이다.

내 정보

UART에 등록한 사용자가 로그인을 하면 뭐… 볼 게 없다. 그러다가 화면 오른쪽 위에 위치한 자신의 이름을 클릭해서 맴버십 페이지로 이동하면 아래와 같은 화면을 만나게 된다. 이 화면은 나의 UART 사용 현황을 한 눈에 보여주는 것인데, 내가 사용하는(Grant한) 앱의 정보, 그 앱 내에서 허용된 역할에 대한 정보, 그리고 로그인에 사용한 신임정보(Credential)를 확인할 수 있는 것이 전부다.

권한 요청

이 화면에서 사용자는 특정 앱에 대하여 자신의 역할을 신청할 수 있다. 일단 사용자가 어떤 앱을 Grant해주고 나면, 그 사용자는 기본적으로 “사용자” 역할을 갖게 된다. 그런데 사용자가 일반 사용자의 권한 이상을 필요로 하는 경우에는 이 페이지로 이동하여 역할신청(Role Request)을 할 수 있다.

위의 그림은 앱의 역할을 신청하는 화면인데, 해당 앱의 여러 역할 중, 내가 아직 가지고 있지 않은 역할의 목록을 보여주게 되고, 이 중에서 원하는 역할을 선택하여 “Request” 버튼을 통해 요청을 날리면 앱의 관리자가 이를 확인하여 역할을 부여하게 된다.

UART와 업무서비스(App)의 연동

반복되는 얘기인데, UART는 등록된 앱에게 인증과 인가를 위한 정보를 제공할 뿐, 자체적으로 업무를 처리하지 않는다. UART를 이용하여 앱의 인증을 하기 위해서는 앱의 관리자가 먼저 앱을 UART에 등록해야 한다.

앱의 등록

앞서 보았던 화면이다. 다음과 같이, 서비스를 등록해줘야 UART를 통한 인증을 받을 수 있다.

이 단계는 시스템적인 연동 설정일 뿐, 이것만으로 모든 구성이 끝난 것은 아니다. 사용자는 자신의 서비스앱이 OAuth2 표준에 의한 인증을 사용할 수 있도록 구성을 해야하며, 그 때 제공자로써 UART를 지정해줘야 한다.

등록된 앱의 인증 동작

아래의 화면은 인증절차의 시험을 위해 제작하여 함께 배포하는 연습용 Client의 동작화면을 뜬 것이다. OAuth2의 인증 절차 등에 대해서는 앞선 글 OAuth2와 JWT, 웹기반 SSO 인증을 참고하면 쉽지 않은 글일 수도 있지만 어느 정도 그 개념을 확인할 수 있다.

이러한 인증 절차를 수용할 수 있도록 프로그램을 만들었다면 부분적으로 사용자 상호작용을 포함하고 있지만 대부분이 기계적 통신으로 이루어진 OAuth2 인증을 할 수 있으며, 그 중 중요한 부분의 정보를 디버깅용으로 찍어보면 아래와 같다.

OAuth2 인증의 첫번째 단계는 인증서버로부터 Authorization Code를 받아오는 것으로부터 시작된다. 이 예에서는 dSJlPTQ-S165-FqhEfMJpQ라는, 그 문자열 자체로는 아무런 의미가 없는 코드를 인증서버로부터 받아와 화면에 출력했다. 이 Authorization Code를 이용하여 Access Token을 요청하는 단계를 거친 후, 그 결과를 화면에 뿌린 것이 두 번째 줄이다.

UART는 완전하게 SPEC을 지원하는 것은 아니지만 Json Web Token, JWT 방식의 Access Token을 발행한다. UART의 인증서를 가지고 있다면 인증서에 포함된 Public Key를 이용하여 이것을 디코딩할 수 있고, 정말 UART가 서명하여 발급한 토큰인지 확인하는 것이 가능하다. 위의 예에서는 Token이 유효하다는 것을 확인한 후, 그것의 정보를 화면에 함께 뿌리고 있다.

그러나 만약, 사용자의 Client가 JWT를 지원하지 않는다면, 세 번째 Phase로 이동하여 사용자 정보를 사용자 정보서버(UART는 이 역할도 함께 수행하지만 개념적으로는 서로 다른 서버일 수 있다)에게 그 정보를 물어볼 수 있다. 물론, 이 때 Access Token을 사용하게 된다. 위 화면의 마지막 줄은 이렇게 사용자 정보를 물어본 결과를 출력한 것으로, 내용이 그 위의 Token에 포함된 정보와 같은 것을 알 수 있다.

수동 Client를 사용하지 않고 Postman을 활용하여 웹브라우저에서 시험해보면 아래와 같은 정보를 볼 수도 있고. 다를 것은 없다.

여기서 UART와 관련하여 눈여겨 볼 부분은 JSON 본문 중간의 roles 부분이다. UART는 사용자가 역할요청을 해서 역할을 가지고 있을 경우에, 사용자 정보를 요청한 앱에 따라 그 앱에서 할당된 역할정보를 이렇게 배열 형태로 함께 전달해주게 되며, 이 값을 받아서 해당 서비스에서는 해당 사용자가 갖는 역할을 확인할 수가 있는 것이다.

정리

UART는 인증통합의 필요성과 소셜인증의 편리함, 폐쇄그룹의 특성을 함께 반영하기 위해 개발된 통합인증 서비스로, 메시징 등의 대부분의 서비스에서 필수로 사용하는 사용자 관련 기능을 함께 제공해준다.

초기 버전이었던 SiSO가 Ruby on Rails로 개발되었던 것과는 다르게, 이번에는 Go 언어를 기반으로 한 웹 서비스로 개발되었으며, 밑에는 Go Buffalo를 프레임웍으로 깔고 있으며, OAuth2 관련 부분은 OSIN OAuth2 server library를 깔고 있다.

아직 범용적이라고 할 만큼 완성도가 높지는 않고, 사용처가 앞으로 얼마나 늘어날지 모르겠지만 나름 재미있는 개발 경험이었다. ㅎ

  1. Service Orientied Architecutre와 유사한 서비스 설계 방식으로, 기능에 따라 세분화된 서비스들이 상호 간섭을 최소화한 채 느슨하게 결합하도록 설계함으로써, 개발과 운영을 단순화시키고 유지보수성을 높여 궁극적으로 서비스 연속성, 신뢰성을 향상시키고자 하는 설계 방식. Microservice Architecture ↩

  2. 일반적인 서비스가 업무 레벨로 제공고, 반대로 서비스에서 사용하는 일반적인 API가 코드 레벨로 제공되어 Deploy 단계에 고정되는 것에 반하여, API as a Service는 기능 자체를 인터넷을 통하여 제공되는 서비스화하여 그것을 제공하는 측과 제공받는 측의 관계를 느슨하게 만들고 독립적인 유지보수성을 확보하며, 효과적으로 기능을 배포하거나 기능 자체에 대한 사업화를 할 수 있는 형태의 서비스라고 생각할 수 있다. API as a Service ↩

  3. 모바일앱 중 상당수는 디바이스 안에서 독립적으로 동작하는 것이 아니라 인터넷을 통한 상호작용을 필요로 하는 경우가 있다. 이런 경우, 이러한 서버측 기능을 제공하기 위하여 개발된 백엔드 서비스를 표현한다. 다른 관점에서 설명하면, 자신의 자체적 UI를 갖추지 않고 다른 Screen에 의존하여 제공되는 서비스로도 볼 수 있다. (API as a Service와 유사한 면이 있으나, 그 제공 수준이 “기능”이기 보다는 “서비스”라는 면에서는 확실한 차이점이 있다고 볼 수 있다. 많은 경우, Mobile Backend as a Service 등으로 표현되는 경우가 많으며 확실히 모바일 분야에서의 용도가 더 강조되기는 하지만, SPA(Single Page Application)을 위한 Backend 역시, 일종의 Backend as a Service로 볼 수 있다. Backend as a Service ↩

  4. 개념의 강조를 위해 사용한 용어이기는 하나, 용어가 가르키는 범위가 상당히 구체적이기 때문에 어떤 면에서는 “용어”라는 표현은 맞지 않을 수 있다. 또한, 다분히 마케딩적인 요소가 강한 문구이기도 하다. ↩