3. CS 스터디 4주차 - SSO 와 OAuth

Lilac-_-P·2023년 5월 15일

Computer Science 공부글

목록 보기

3/11

대부분의 IT 서비스를 사용하기 위해서는 인증과 인가의 절차가 필수적이다.

인증(Authentication)은 사용자가 누구인지 확인하는 절차이고, 인가(Authorization)은 사용자가 요청하는 자원(Resource)에 대해 권한(Permission)이 있는지를 확인하는 절차이다. 서비스 제공자는 인증과 인가를 통해 서비스에 접근하는 익명의 누군가가 서비스를 사용할 수 있는 사용자가 맞는지, 서비스를 사용할 수 있는 사용자라면 어느 범위까지의 서비스를 사용할 수 있는 사용자인지 확인할 수 있다.

로그인 -> 인증
로그인한 특정 사용자가 ?를 할 권한 -> 인가

이전에는 여러 서비스마다 각각 계정을 만들어서 각 서비스에 맞는 계정을 사용하는 일들이 많았는데, 최근에는 SSO의 등장과 함께 대형 IT 기업(ex. 구글, 네이버, 페이스북, 카카오, 애플 등)의 계정으로 로그인을 대신하는 경우가 많아졌다.

SSO(Single Sign On)

직역하면 단일 로그인, 즉 한번의 로그인으로 여러개의 애플리케이션들을 이용할 수 있게 해주는 서비스이다.
SSO가 없다면 사용하고자 하는 서비스마다 따로따로 계정을 갖고 있어야 한다.

하지만, SSO가 도입된다면 서비스마다 개별적으로 계정을 만드는 대신 하나의 계정으로 연관된 서비스들을 사용할 수 있다.

SSO의 도입을 통해 사용자는 서비스별 계정을 모두 만들어서 기억할 필요가 없게 되고, 서비스 관리자 또한 서비스별로 인증시스템을 구축할 필요가 없게되어 하나의 계정으로 어러 시스템과 플랫폼, 기타 리소스에 대한 사용자 접근을 관리할 수 있다.

SSO의 구현 모델

Delegation Model(인증 대행 모델)

대상 서비스의 인증 방식을 변경하지 않고, 사용자의 인증 정보를 Agent가 관리하여 대신 로그인해주는 방식이다.
Target Service에 로그인하기 위한 정보를 SSO agent가 가지고 있고 로그인할 때 유저 대신 대상 서비스로 정보를 전달하여 로그인시켜 주는 원리로 작동한다.

막연한 추측.
Legacy 프로젝트에 사용될 가능성이 높다. User가 Sign On Agent에 인증할 때 사용하는 인증 정보와 실제 Target Service에 접근할 때 사용하는 인증정보를 바인딩하여 저장소에 갖고 있을 것 같다.

Propagation Model(인증정보 전달 모델)

통합 인증을 수행하는 곳에서 인증을 받아 ‘인증 토큰'이란 것을 발급받는다.
사용자가 서비스에 접근할 때 발급받은 인증토큰을 서비스에 같이 전달하게 되고, 서비스는 토큰정보를 통해 사용자를 인식할 수 있게 하는 방식이다.

들 수 있는 의문.
Google - Gmail, Youtube, Google Drive 의 관계(First Party App)
Google - Third Party App 의 관계(Third Party App)

SSO는 여러 표준, 프레임워크에 의해서 구현될 수 있다.

대표적으로 SAML, OAuth, OIDC 세가지 방식이 있는데, 웹 서비스에서 가장 흔하게 사용되는 OAuth에 대해 알아보자.

OAuth

사실 OAuth 프로토콜은 인증을 목적으로 하는 프로토콜은 아니다. 프로토콜의 이름에도 들어있듯이 인가(Authorization)을 위한 프로토콜인데, 생각해보면 인증과 인가는 서로 밀접하게 연관되어있어 떼어놓고 설명할 수 없다. 인가 처리를 위해서는 사용자에 대한 인증이 필요하기 때문이다.

참고.
OAuth 프로토콜의 주된 목적은 인가처리가 맞다. 하지만, 인가 처리를 위해 필수적으로 인증이 필요하기 때문에 OAuth 프로토콜을 인증의 용도로도 사용할 수 는 있는 것이다.(Pseudo-Authentication)

OAuth2.0 구성요소

OAuth 프로토콜을 이용하여 SSO 시스템을 구성하는 경우 아래와 같은 구성요소에 대한 이해가 필요하다.

Resource Owner: 로그인을 제공하는 플랫폼(네이버, 카카오, 페이스북 등)에 회원가입을 하여 계정을 가지고 있으며 Client가 제공하는 서비스를 이용하려는 사용자. Resource Server에 계정을 가지고 있는 사용자. (Resource는 개인정보라고 생각하면 된다.)
Client: OAuth2.0을 이용해 로그인 기능을 구현할 주체 서비스
Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버. 사용자는 이 서버로 ID/Password를 넘겨 인증 코드를 발급받는다. Client는 이 서버로 인증 코드를 넘겨 Access Token을 발급받는다.
Resource Server(API Server): 사용자의 개인정보를 가지고 있는 웹 애플리케이션(네이버, 카카오, 페이스북, 구글, 애플 등)서버이다. Client는 Access Token을 이 서버로 넘겨 개인정보를 응답받는다.