OAuth 2.0 에 대하여

안녕하세요. 오늘은 OAuth 2.0 에 대하여 알아보겠습니다.

 

▣ OAuth 2.0 이해를 위한 용어 정리

1. 인증 (Authentication) - 신원을 확인하는 것

자신이 A 라고 주장하는 고객이 정말로 A 본인이 맞는 것인지 확인하는 것을 뜻합니다. 예를 들어 앱을 통해 계좌를 개설할 때 주민등록증 사진, 이름, 생년월일, 휴대폰인증 등이 요구되는데 이러한 부분이 인증에 해당합니다.

 

2. 승인 (Authorization) - 권한을 부여하는 것

통제된 자원에 대해 자원의 주인이 클라이언트 접근에 대해 행하는 승낙이나 동의를 뜻합니다.

 

▣ OAuth 2.0 의 등장 배경

일반적인 인증 방식으로는 아이디와 비밀번호로 로그인 하는 방식이 많이 사용되어 왔습니다. 서버는 클라이언트로부터 아이디와 비밀번호를 받은 뒤 체크 후, 클라이언트에게 세션(쿠키)을 발행하면 클라이언트는 통제된 자원과 기능에 대해 접근이 가능했었습니다.

 

하지만 이러한 쿠키 기반 권한 부여는 몇가지 단점 및 취약점을 내재하고 있습니다.

 

1. 매번 들어오는 요청마다 세션(쿠키)의 회원 정보의 상태에 대해 DB 조회를 해야 합니다.

2. 세션(쿠키)은 도메인에 종속되어 있기 때문에, 여러 도메인과 상호작용 되는 서비스인 경우 별도 설정을 해주어야 합니다.

3. 세션(쿠키) 승인 방식은 모바일 앱에는 적합하지 않습니다. 모바일 앱에서 쿠키 기능도 결국 브라우저를 기반으로 이루어지기 때문입니다.

4. 세션(쿠키) 승인 방식은 여러 서비스 간에 데이터를 공유하기 어렵습니다. 세션(쿠키)는 도메인에 종속적이기 때문입니다.

 

위와 같은 문제점 때문에 OAuth2 가 나오게 되었습니다.

 

▣ OAuth 2.0 에 등장하는 이해관계자 각각의 역할

1. 앱 (Client)

사용자 데이터를 이용하여 서비스를 제공하는 역할을 합니다. 사용자 (Resource Owner) 로부터 데이터 활용에 대한 동의를 받고, 사용자 대신 권한 제공자에게 요청을 보내 로그인을 진행합니다.

(ex. 옥션, 11번가, 에어비엔비, 스푼 등)

 

2. 데이터 제공자 (Resource Server)

사용자가 동의한 앱 (Client) 한테만 데이터를 제공하는 역할을 합니다.

(ex. 구글, 애플, 카카오톡, 네이버, 페이스북 등)

 

3. 권한 제공자 (Authorization Server)

앱에서 요청하는 종류에 따라 권한을 제공하며, 사용자에게 앱에 대한 등록 정보와 앱에서 요청한 데이터 항목에 대한 정보를 알려주고 사용자의 동의 여부를 묻는 역할을 합니다. 소규모인 경우 데이터 제공자와 권한 제공자가 하나의 그룹에서 모두 이루어지는 경우도 있지만, 규모가 클수록 데이터 제공자와 권한 제공자를 분리해서 구현 하는 경우가 많습니다. 권한 제공자는 요청온 클라이언트가 정말 사용자에게 권한을 위임 받은 클라이언트가 맞는지 의심하고 확인하려고 합니다.  

 

4. 사용자 (Resource Owner)

데이터 제공자 입장에서 사용자는 데이터 관리를 맡긴 고객이고, 앱의 입장에서 사용자는 가치를 창출하기 위해 필요한 데이터의 주인입니다. 사용자는 임의로 자신의 데이터에 대한 접근 권한 부여, 거부, 철회를 할 수 있고 데이터 범위 및 제공 기간 등을 정할 수 있는 데이터의 주체입니다.  

(ex. 가맹점주, 대학생, 주부, 회사원 등)

 

▣ OAuth 2.0 에 사용되는 데이터

1. 앱 정보

OAuth 2.0 을 사용하고자 하는 앱은 사전에 권한 제공자에게 앱에 대한 정보를 등록해야 합니다. 일반적으로 앱에서 제공할 서비스의 명칭, 사이트 주소, 로고, Redirect URI 등의 기본 정보를 등록합니다. 

 

2. Redirect URI

권한 제공자는 사용자가 앱에게 권한을 부여하는 것에 대해 동의를 하면 사용자를 앱 정보 중에 하나인 Redirect URI 로 이동시킵니다. 만약 사전에 등록된 앱 정보의 Reditect URI 가 아닌 다른 URI 이면 이동되지 않습니다. Redirect URI 로 이동 할 때 권한 제공자는 authorization code (임시 승인 코드)를 담아 보냅니다.

 

3. Authorization code

앱 (Client) 이 권한 제공자 (Authorization Server) 에게 사용자 (Resource Owner) 로부터 여러 기능 (scope) 에 대해 사용할 것을 동의를 받았다고 요청을 보내면 권한 제공자는 앱의 Redirect URI 로 사용자를 이동시킬 때 Authorization code 을 담아 이동시킵니다. Authorization code 는 사용자를 식별 할 수 있는 임시 승인 코드이며, 앱은 이 Authorization code 를 받아 자신이 사용자가 동의한 앱임을 증명하기 위해 권한 제공자에게 Redirect URI, Authorization code, Client ID, Client Secret 이렇게 4개 값을 요청합니다. 그럼 권한 제공자는 지금 요청온 앱이 사용자가 권한을 위임한 그 앱이 맞다는 걸 인식하여 앱에게 Access Token, Refresh Token 을 발급합니다.

 

4. Client ID, Client Secret

Client ID 는 앱(서비스)을 식별하는 식별자 이고, Client Secret 은 Client ID 에 대한 비밀번호로 외부에 노출되어서는 안되는 값입니다. 

 

5. Access Token & Rrefresh Token

앱(Client)은 권한 제공자(Authorization Server) 에게 받은 Access Token 을 이용해 데이터 제공자 (Resource Server) 에게 데이터 요청을 합니다. 데이터 제공자는 요청 값에 담긴 Access Token 을 확인하여, 데이터를 제공하거나 제공하지 않을 수 있습니다. Access Token 은 보통 유효 기간이 짧게 발행되는데, 만료되었을 경우에는 Refresh Token 으로 권한 제공자에게 간단하게 신규 Access Token 을 재발급 받을 수 있습니다.

 

▣ OAuth 2.0 인증 구조도

앞서 정리한 내용을 바탕으로 OAuth 2.0 인증 과정을 구조도로 정리해 보면 다음과 같이 정리해 볼 수 있습니다.

좀 더 자세히 보실 수 있게 PDF 파일로도 첨부합니다.

 

OAuth2 인증 과정 구조도.pdf

0.27MB

 

 

잘못된 부분이 있다면 댓글로 남겨주시면 감사하겠습니다!

 

 

 

출처

https://www.2e.co.kr/news/articleView.html?idxno=208569

https://www.2e.co.kr/news/articleView.html?idxno=208594

https://velog.io/@rohkorea86/oAuth%EC%9D%B4%EB%A1%A0