OAuth2.0 개요

OAuth의 등장 배경

OAuth가 등장하기 이전에는 보안 인증 방식에 대한 표준이 없었기 때문에 웹 기반의 서비스를 제공하는 기업들이 독자 적인 방법으로 인증 처리를 하였습니다. 그리고 이러한 웹이 발전하면서 분산된 각자의 서비스들이 서로 의존하고 Open API 등을 통해서 서비스들끼리 정보를 공유하는 상황으로 발전하였습니다.

 

이에 따라 다른 기업과 개인, 다른 서비스들끼리 서로 정보를 공유하기 위해서는 대부분은 인증이라는 보안 검증 절차가 이루어져야 합니다.

 

하지만, 기업들의 각자의 독자적인 방식의 인증 수단을 이용하였기에 서로 다른 인증 처리를 위해서는 많은 보안 문제점 발생하였겠지요

 

이를 해결하기 위해서 공식 표준안인 OAuth가 등장하였습니다.

 

OAuth2 활용 예

OAuth를 활용하는 몇 가지 예를 들어 보겠습니다.

첫 번째 예로

(각각 다른 기업 서비스인) 서비스 A와 구글의 캘린더 서비스가 있습니다.
또한, USER1이라는 사용자는 서비스 A와 구글에 각각 가입하여 사용하고 있습니다.

서비스 A는 (USER1을 대신하여) 구글 캘린더로부터 USER1의 일정 정보를 가져와 비서 역할도 하고, 사용자를 대신하여 일정을 관리해주는 기능을 한다고 합니다.

이러한 서비스를 위해서는 USER1은 서비스 A에게 자신의 구글 인증정보(ID와 비밀번호)를 제공하여야 합니다.

만약, 서비스 A가 신뢰도가 부족한 신생 기업이라면 비밀번호와 같은 민감한 정보를 제공하는 것은 매우 위험할 수 있습니다. (나의 정보를 이용하여 불법적인 일을 하는 나쁜 기업일 수도 있겠지요)

 

하지만 OAuth2를 이용하면 사용자는 (서비스 A를 거쳐 ) 구글로부터 유효한 사용자라는 것을 인증하고 access Token이라는 것을 발급 받음과 동시에 리다렉이션되어 서비스 A로 access Token이 전달이 됩니다.

서비스 A는 이 Access Token을 이용하여 사용자를 대신해서 구글 캘린더 서비스의 일부 기능들을 이용할 수 있는 권한을 가지게 됩니다.

 

access Token에는 다음의 주요한 정보들을 내포하고 있습니다.

1. USER1은 구글에 유효한 인증을 가진 자이다.
2. USER1의 사용할 수 있는 구글의 여러 기능 중 일부 기능을 서비스 A에게 위임을 허용한다. (즉 서비스 A는 USER1을 대신하여 구글의 특정 기능을 사용 & 조작할 수 있다.)
3. Access Token은 일정한 유효 시간이 있다. (Access Token 유효기간이 짧을수록 재발급을 자주 받아야 하는 불편함이 생기지만 보안성이 높아진다.)

* 자세한 메커니즘은 설명이 너무 길어지기에 다음 포스팅에서 하나씩 다루면서 실제 인증 서버도 구축해 보겠습니다.

 

 

두 번째 예로는

구글에 가입되어 있는 사용자가 A 서비스에 가입하려고 합니다.
A 서비스는 구글에 연계된 서비스이기에 구글의 계정 정보를 이용하여 가입할 수 있습니다.
이때에도 서비스 A에게 자신의 구글 인증정보(ID와 비밀번호)를 제공하는 것이 문제가 될 수 있습니다.

위의 예에서 OAuth를 이용하면 구글 인증정보를 서비스 A에게 직접적으로 제공하지 않고 보다 안전한 방법으로 인증이 가능합니다. 또한 구글의 모든 기능이 아닌 특정 기능만을 위임받도록 허용하는 것도 가능합니다.
(자세한 방식은 아래에서 설명드리겠습니다.)

 

마지막 예 하나 더 들어 보겠습니다.

위의 예와 같이 서로 다른 기업의 다른 서비스가 아닌, 하나의 기업 서비스의 여러 애플리케이션끼리 서로 통신하며 정보를 공유하는 경우가 많이 있습니다. 최근 핫한 마이크로 서비스 아키텍처가 그 예가 될 수 있습니다.
하나의 서비스 안이라고 하더라도 각각의 애플리케이션 사이에 통신이 이루어진다면, 안전을 위해 서로 인증 및 인가 처리가 필요합니다. 이러한 경우, 자체적으로 구현하는 것보단 "웹 표준인 잘 만들어진 OAuth2"를 이용하는 것이 시간적으로나 안정성 면에서도 훨씬 유리할 수 있습니다.

 

또한, 서비스가 크게 성공하여 향후 다양한 기업의 서비스와 연계를 하게 될 때에도 이미 만들어 놓은 인증 서버를 그대로 활용하는 것도 가능할 것입니다.

 

* 위의 예에서 언급한 마이크로 서비스 아키텍처(MSA)와 Spring Cloud를 이용한 MSA 구현 대해서 더 자세히 알고 싶으신 분들은  본 블로그의 "Spring Cloud 카테고리"를 보시면 도움이 되실 듯합니다. Spring Cloud 카테고리 링크 개념부터 구현까지 여러 포스팅에 거쳐서 글을 작성하였습니다.

 

인증과 인가

OAuth2를 이해하기 위해서는 인증과 인가에 대한 개념을 이해해야 합니다. (OAuth 뿐만 아니라 보안에 관련한 필수적인 개념이기에 간단한 정의를 숙지할 필요가 있습니다.)

 

인증 (Authentication)

어떠한 서비스를 이용하기 위해 유효한 사용자인지 확인하는 절차

 

인가 (Authorization)

서비스의 여러 자원(기능 등) 중에 특정 자원에 접근할 권한이 있는지 확인하는 절차

 

인증과 인가에 대해 예를 들어 보겠습니다.

 

서비스 A가 있습니다. 이 서비스는 회원제로 운영되기에 반드시 회원가입을 한 사용자만 이용할 수가 있습니다.

또한 무료회원과 유료회원으로 구분되어 있기에 무료회원은 유료회원 전용 정보에는 접근할 수가 없습니다.

 

무료 사용자인 USER1이 서비스 A에 최초 접속하여 서비스를 이용하기 위해 ID/비밀번호로 로그인을 하며 이를 통해 유효한 사용자인지 검증합니다. 이를 인증 (Authentication)이라고 합니다.

 

또한 로그인 이후 USER1은 무료 정보만을 확인할 수 있으며, 유료 전용 정보는 메뉴가 보이지 않거나 접근을 시도할 시에 허용되지 않는 회원이라는 오류 메시지와 함께 접근이 거부됩니다. 이러한 검증을 인가 (Authorization)라고 합니다.

 

OAuth2의 4가지 그랜트 타입 (Grant Type)

OAuth에는 4가지 그랜트 타입이 존재하며, 각각은 메커니즘이나 활용 방법이 다릅니다. 각각의 내용 또한 작지 않은 분량이기에 이번 포스팅에서는 간단한 개요만 알아보고 다음 포스팅부터 하나씩 자세히 살펴보도록 하겠습니다.

 

패스워드 그랜트 (Password Credentials Grant)

위의 "OAuth2 활용 예" 중에서 세 번째 예에 주로 사용됩니다.

 

사용자가 이용하는 클라이언트(혹은 모바일 웹,앱) 및 서비스 애플리케이션이 모두 하나의 기업 혹은 기관에서 소유하고 있을 경우 적합한 방법입니다.

사용자는 ID와 비밀번호를 이용하여 인증서버에 1회 인증을 거쳐 Access Token을 발급받습니다.

이후 클라이언트는 이 Access Token을 이용하여 여러 서비스 애플리케이션을 이용할 수 있습니다.

 

클라이언트 자격 증명 그랜트 (Client Credentials Grant)

패스워드 그랜트와 마찬가지로 위의 "OAuth2 활용 예" 중 세 번째 예에 주로 사용됩니다. 차이점이 있다면 사용자의 개입이 없다는 것입니다.

예를 들어 하나의 기업의 애플리케이션 중에 자동적으로 반복 수행하는 배치 서비스가 있습니다. 이 배치 서비스는 다른 여러 서비스의 자원에 접근해 정보를 가져와야 하기에 인증서버를 거쳐 Access Token을 발급받아야 합니다.

단, 사용자의 개입이 없기에 사용자의 ID와 비밀번호 없이 Access Token 획득이 가능합니다.

하여 외부와 단절된 내부망의 여러 서비스들끼리의 인증 작업에 적합한 방법입니다.

 

권한 부여 코드 그랜트 (Authorization Code Grant)

위의 "OAuth2 활용 예" 첫 번째와 두 번째 예에 주로 사용되며, 처리되는 메커니즘이 가장 복잡한 방법입니다.

위의 활용 예를 통해 사용자와 서비스(위의 예의 구글) 그리고 제3자의 클라이언트(위의 예의 서비스 A) 간의 인증 절차를 잘 유념해두시고 자세한 메커니즘은 내용이 상당히 길기에 따로 포스팅으로 다루도록 하겠습니다.

 

암시적 그랜트 (Implicit  Grant)

권한 부여 코드 그랜트와 유사하지만 차이점이 있다면 권한 부여 코드 그랜트의 "제3자의 클라이언트"는 자바와 .NET과 같은 전통적인 서버 측 프로그래밍 환경에서 실행됩니다.

그에 반해 암시적 그랜트는 서버 측 기술을 사용하지 않은 순수 자바스크립트의 클라이언트 기반으로 OAuth 인증 및 토큰 획득이 가능합니다.

 

OAuth2의 주요 구성 요소

OAuth2의 상세한 메커니즘을 이해하기에 앞서 주요 구성 요소 몇 가지를 먼저 파악하여야 합니다.

 

인증 서버 (OAuth2 Sever)

인증, 인가를 통해 관리되는 리소스에 대한 전반적인 보안 관리를 맡고 있는 서버입니다.

적절한 인증, 인가를 거쳐 Access Token을 발급하고 유효성을 검증하는 역할을 합니다.

 

리소스 서버 (API 등 자원을 보유한 서버)

USER가 사용할 리소스들이 있는 서버입니다.

 

리소스 소유자 (Resource Owner, 사용자)

클라이언트를 사용하는 USER이며, 자신의 자격(ID/비밀번호) 증명을 통해서 Acesss Token을 발급되어 클라이언트에서 권한을 위임합니다. 

예를 들어 구글에 로그인하여 구글 캘린더의 자신만의 일정(리소스, 자원)을 제어할 수 있는 일반 사용자를 뜻합니다.

간혹 특정 책 혹은 매체에서는 리소스 소유자를 리소스 서버의 관리자로 지칭하기도 합니다. 이는 틀린 표현이 아닐수 있으며 예시에 따라 달리 사용되는 경우로 보입니다.   하지만 용어만 같고 각각은 전혀 다른 주체들입니다.  이 포스팅에서는 일반 사용자로 지칭하겠습니다.

 

클라이언트

클라이언트는 제3자(Third-Part)의 서비스이거나 자사의 클라이언트 서비스 입니다.

사용자를 대신하여 인증서버로부터 Access Token을 획득하고 리소스 서버로 부터 자원을 활용합니다.

 

* 제3자(Third-Part)의 서비스란

  인증 서버와 다른 기업의 애플리케이션 혹은 클라이언트 서비스를 의미 합니다.

 

 

단순히 글로만 짧게 명시하니 명확한 의미가 잘 와닿지 않을 수 있습니다. 위의 구성요소를 인지한 상태에서 다음장부터 하나씩 상세한 동작 메커니즘을 확인하면 쉽게 이해하실 수 있을 겁니다.

 

마무리

이로서 OAuth2가 나오게 된 배경과 어떠한 상황에 활용이 되는지에 대해 확인하고 4가지 그랜트 타입을 간단히 알아보았습니다. 또한 보안의 중요한 요소인 인증과 인가에 대해서도 학습하였습니다.

다음 포스팅에서는 패스워드 그랜트와 클라이언트 자격 증명 그랜트의 메커니즘을 더 자세히 알아보도록 하겠습니다.

 

 

참고

https://ko.wikipedia.org/wiki/OAuth

스프링 마이크로서비스 코딩 공작소 길벗