OAuth2 복습
OAuth 2란?
앞에서의 예시와 같이 여러분들이 웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2라는 기술을 바탕으로 구현됩니다.
전통적으로 특정 애플리케이션의 서비스를 이용하는 사용자에 대한 인증 처리는 해당 서비스를 직접적으로 제공하는 애플리케이션에서 담당해 왔습니다.
인증 서버를 별도로 분리해서 인증을 처리하든 하나의 서버에서 사용자의 인증도 처리하고 그와 동시에 애플리케이션의 서비스도 함께 제공하든 어쨌든 서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜(Credential)을 직접적으로 관리하는 것이 일반적입니다.
예를 들어 사용자에 대한 일정 관리 서비스를 제공하는 애플리케이션이 있다고 가정하겠습니다. 이 일정 관리 서비스는 특별히 외부의 써드 파티 애플리케이션과의 통신 없이 자체적으로 회원의 크리덴셜(Credential)을 관리하는 단순한 애플리케이션입니다.
이 경우 [그림 4-29]와 같이 자신의 백엔드 애플리케이션에서 회원의 크리덴셜(Credential)을 관리합니다.
[그림 4-29] 전통적인 애플리케이션에서 사용자의 크리덴셜을 저장하는 아키텍처
그런데 OAuth 2는 [그림 4-29]와 같은 전통적인 인증 처리 방식과 조금 다른 처리 방식으로 동작합니다.
예를 하나 더 들어보겠습니다.
앞에서 언급한 사용자의 일정 관리 서비스를 제공하는 애플리케이션에서 사용자에게 캘린더 형태의 서비스를 제공하기 위해 Google의 Calendar API를 이용하는 기능이 추가되었다고 가정하겠습니다.
이 경우, 아래의 [그림 4-30]과 같이 일정 관리 서비스에 대한 회원 가입을 통해 사용자의 크리덴셜(Credential)을 관리해야 함은 물론이고, Google의 Calender API를 이용하기 위해 Google에서 사용하는 사용자의 크리덴셜(Credential)까지 일정 관리 서비스와 공유해야 합니다.
[그림 4-30] 써드 파티 API를 사용을 위해 써드 파티 애플리케이션의 크리덴셜을 저장하는 아키텍처
이렇게 되면 어떤 문제점이 발생할까요?
사용자가 일정 관리 서비스에 대한 회원 가입을 하는 시점 또는 캘린더 서비스를 사용하는 시점에 Google Calendar API를 이용하기 위해 Google에서 사용하는 사용자의 크리덴셜(Credential)을 일정 관리 서비스 애플리케이션에 추가적으로 제공해야 합니다. 그리고 제공한 Google에 대한 크리덴셜(Credential)은 일정 관리 서비스 애플리케이션 어딘가에 저장될 테고요.
- 우선 사용자에게 가장 중요한 정보인 크리덴셜(Credential)이 두 개나 관리돼야 합니다.
- Google 사이트에서 패스워드를 변경하더라도 변경된 Google의 패스워드를 일정 관리 서비스 애플리케이션에서 추가로 업데이트해 주어야 합니다.
- 일정 관리 애플리케이션이 Google 사이트에서 사용하는 크리덴셜(Credential)을 직접적으로 가지고 있는 것도 보안상 심각한 문제입니다. 한마디로 보안 침해 사고라도 발생한다면 심각한 피해가 발생하기 딱 좋은 상황인 것입니다.
이런 문제점을 보완하는 효과적인 방법 중 하나는 Google에서 사용하는 사용자의 크리덴셜을 일정 관리 서비스 애플리케이션에서 직접적으로 관리하지 않으면서도 Google Calendar API를 이용할 수 있게 하는 것입니다.
이런 방식으로 동작하는 애플리케이션을 구현하는 것이 가능할까요?
바로 OAuth 2 인증 프로토콜을 사용하면 가능합니다.
OAuth 2는 특정 애플리케이션(Client)에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해 주고 Resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식입니다.
즉, 앞에서 언급한 일정 관리 서비스 애플리케이션을 예로 들어 OAuth 2 인증 프로토콜에 대한 개념을 간단히 정리하자면, 아래의 [그림 4-31]과 같이 일정 관리 서비스 애플리케이션을 사용하는 사용자의 Google 전용 크리덴셜(Credential)이 일정 관리 서비스 애플리케이션에 직접적으로 제공되지 않아도 됩니다.
로그인 자체는 구글 로그인 인증을 이용하고, 구글 로그인에 성공하면 Access Token을 전달받아서 Google Calendar API를 사용하기 위해 Access Token을 이용합니다.
[그림 4-31] 써드 파티 애플리케이션의 크리덴셜을 저장하지 않는 아키텍처
일정 관리 서비스 애플리케이션에 구글의 크리덴셜(Credential)이 직접적으로 제공되지 않기 때문에 일정 관리 서비스 애플리케이션에서 사용하는 크리덴셜(Credential) 저장소에 저장될 필요가 없으므로 사용자의 크리덴셜(Credential)을 이중으로 관리하지 않아도 됩니다.
관리하는 크리덴셜(Credential)이 줄어든다는 것은 그만큼 보안성도 향상된다는 의미와 같습니다.
그렇다면 OAuth 2는 어떤 유형의 애플리케이션에서 주로 사용할 수 있을까요?
OAuth 2를 사용하는 애플리케이션 유형
1️⃣ 써드 파티 애플리케이션에서 제공하는 API의 직접적인 사용
첫 번째로 Google, Github, Facebook 같은 신뢰할만한 써드 파티 애플리케이션에서 제공하는 API를 직접적으로 사용하는 애플리케이션을 구현하는데 OAuth 2를 사용할 수 있습니다.
사용자가 OAuth 2 인증 프로토콜을 이용해 써드 파티 애플리케이션에 대한 인증에 성공하면 써드 파티 애플리케이션에서 제공하는 API를 활용한 커스텀 서비스를 제공하는 것입니다.
2️⃣ 추가적인 인증 서비스 제공 용도
두 번째는 써드 파티 애플리케이션의 서비스를 이용하는 것뿐만 아니라 추가적인 인증 서비스를 제공하기 위한 용도로 사용하기 위함입니다.
쉽게 말해서 일반적으로 제공하는 아이디/패스워드 로그인 인증 이외에 OAuth 2를 이용한 로그인 인증 방법을 추가적으로 제공하는 것입니다.
만약 특정 서비스를 제공하는 애플리케이션에서 사용자의 크리덴셜(Credential)을 남기고 싶지 않을 경우 OAuth 2 로그인 인증 방법으로 로그인하면 됩니다.
앞에서 언급한 OAuth 2를 사용하는 애플리케이션 유형이 지금은 머릿속에 그려지지 않겠지만 이어지는 챕터에서 설명하는 OAuth 2 인증 아키텍처의 구성요소와 OAuth 2의 동작 방식 등을 학습하고 나면 OAuth 2 기반의 애플리케이션에 대해 조금 더 구체적으로 이해할 수 있을 거라 생각합니다.
핵심 포인트
- OAuth 2는 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해 주고 접근 권한에 대한 토큰을 발급한 뒤 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식이다.
- OAuth 2를 사용하는 애플리케이션 유형
- 써드 파티 애플리케이션에서 제공하는 API를 직접적으로 사용
- 추가적인 인증 서비스를 제공하기 위한 용도
심화 학습
- OAuth 2에 대해서 조금 더 알아보고 싶다면 아래 링크를 참고하세요.
