[모각코] Auth 2.0 개념 및 동작방식 설명

OAuth 2.0

목차(index)

1. 소개(introduction)
2. 역할(Role)
3. OAuth 2.0의 권한 승인 과정 및 방법
4. OAuth 2.0의 장점

소개(Introduction)

기존의 Client-Server 인증(Authentication) 모델에서 client는 자원 소유자(이하 user, resource owner)의 credentials(id, password 같은 user를 인증할 수 있는 정보)를 사용해서 server에 인증하여 server에서 접근이 제한된 자원(이하 *보호된 자원, protected resource)을 요청합니다. third party application(이하 **myapp.com, 내가 만든 사이트)에게 보호된 자원에 접근할 권한을 주기 위해 user는 credentials를 myapp.com과 공유하게 된다. 이러한 방법으로 인해 아래와 같은 문제가 발생합니다.

*접근이 제한된 자원: 구글 캘린더, 페이스북 친구목록 등과 같이 외부 서버에 있는 개인정보

• user측면에선 myapp.com에 다른 사이트(ex. 구글, 페이스북)의 credentials를 공개하는 것을 신뢰할 수 없다.
• myapp.com의 측면에선 user의 credentials를 받았기에 보안 문제가 생기는 경우 모든 책임을 져야한다.
• myapp.com에 비해 규모가 큰 다른 사이트 입장에서는 myapp.com을 신뢰할 수 없다.

위와 같은 문제를 해결하기 위해 2006년에 트위터 개발자와 Gnolia의 개발자가 안전한 인증방식에 대한 논의를 하면서 OAuth가 등장했고 2010년에 OAuth1.0이 발표되었다. 현재는 OAuth 1.0a를 거쳐 OAuth 2.0이 많이 사용되고 있다.

OAuth 란?

Open Authorization의 약자로 다양한 플랫폼에서 권한 부여를 위한 산업 표준 프로토콜이다.
자세히 설명하면, 제3의 앱(=myapp.com)이 서비스이용자(=user)를 대신하여 서비스를 요청할 수 있도록 자원 접근권한을 위임하는 방법

역할(Role)

역할	설명
Resource Server (자원 서버)	OAuth2.0 서비스를 제공하고, 보호된 자원에 대한 서비스 API를 제공하는 서버
Resource Owner (자원 소유자)	Resource Server의 계정을 소유하고 있는 사용자 (User, 일반적인 사용자)
Client	Resource Server의 API를 사용하여 데이터(ex. 보호된 자원)를 가져오려고 하는 사이트 (myapp.com, 내가 만든 사이트)
Authorization Server (권한 서버)	Client가 Resource Server의 서비스를 사용할 수 있게 인증하고 토큰을 발행해주는 서버 (인증 서버)

OAuth 2.0의 권한 승인 과정

Step	Describtion
①	클라이언트가 자원 소유자에게 자원에 대한 접근 권한을 직/간접 요청 ·①-a : 자원 소유자에게 직접 요청 ·①-b-1 : 권한 서버를 중개자로 간접적으로 요청(권장) ·①-b-2: Redirect URI를 통해 User를 권한 서버로 리다이렉션 시키며, 권한 서버가 Client를 식별할 수 있도록 식별 정보(ex. Client ID, Client Secret) 를 함께 전달
②	Client에게 자원에 대한 접근 권한을 승인(4가지 권한 승인 방법 중 하나 사용, Authorization Code Grant 방식을 많이 사용)
③	Client가 권한 서버에게 Access 토큰을 요청
④	권한 서버는 Client를 인증 및 부여 받은 권한을 검증하고, 검증된 경우 Client에게 Access 토큰을 발급 ·권한 승인 방법에 따라, 선택적으로 Access 토큰의 유효기간 만료 시 Access 토큰 재발급을 위한 Refresh Token(재발급 토큰) 추가 발급
⑤	Client가 자원 서버에게 Access 토큰으로 인증 및 자원을 요청
⑥	자원 서버는 Access 토큰을 검증하고, 검증된 경우 서비스 제공

등록(Register)

OAuth 2.0에서는 자원 서버에게 API 요청을 한 Client를 식별 및 검증하기 위해, 먼저 권한 서버에 Client를 "등록" 시켜놔야 한다.

서비스마다 등록하는 방법은 다를 수 있지만 Client ID, Client Secret, Authorized redirect URls라는 세가지 요소는 공통적으로 가진다.

Client ID: myapp.com을 식별하는 식별자, 외부에 노출되어도 괜찮다

Client Secret: Client ID에 대한 비밀번호, 외부에 노출되면 안된다.

Authorized Redirect URls: User가 Client의 자원 접근권한을 승인한 경우 Access 토큰, Authorization Code 등의 Credential 정보가 반환될 URI.

※URI 와 URL의 차이

URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미한다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스다.

URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약이고 URI의 하위집합이다.

OAuth 2.0의 Client 유형 및 설명

Client 유형	설명
웹 애플리케이션	웹 서버 상에서 실행되는 애플리케이션으로 자원 소유자는 HTML 및 웹 브라우저 또는 별도의 웹 클라이언트를 통해 접속
이용자 에이전트 애플리케이션	웹 브라우저 등 이용자의 에이전트 상에서 실행되는 애플리케이션으로 클라이언트 측 스크립트 (ex. 자바 스크립트) 및 웹 브라우저 확장 프로그램 형태 등으로 배포
네이티브 애플리케이션	PC, 스마트폰 등과 같은 이용자 단말에 직접 설치 및 실행되는 애플리케이션

OAuth 2.0의 권한 승인 방법

Client 유형, 보호된 자원에 대한 장기적 접근 여부 및 제공 서비스의 특성 등에 따라, 총 4가지 권한 승인 방법으로 나뉜다.
(4가지 승인방법 중 제일 안전하고 편리한 권한 코드 승인 방법이 제일 많이 사용된다.)

권한 코드 승인 (Authorization Code Grant)	암묵적 승인 (Implicit Grant)
-클라이언트 유형 · 서버 웹 애플리케이션 · 네이티브 애플리케이션(백엔드 서버 사용) -장기적 접근 ·Refresh Token(재발급 토큰)을 통해 지원 -보안성 · 웹 브라우저를 통해 Access 토큰이 노출되지 않도록 권한 코드 사용 · 클라이언트는 권한 코드를 사용하여 권한 서버에게 직접 Access 토큰을 요청 · 중요 자격증명 정보(credential information)가 서버에 저장되기 때문에 다른 권한 승인 방법에 비해 안전함	-클라이언트 유형 ·이용자 에이전트 애플리케이션 -장기적 접근 ·Refresh 토큰 미지원으로 인해 Access 토큰의 유효 기간이 짧으면 장기적 접근 불가 -보안성 ·Access 토큰이 웹 브라우저에 전달 및 저장되기 때문에 웹 브라우저, 클라이언트, 이용자에 대한 신뢰가 높은 경우에 적합 ·Access 토큰 유출을 고려하여, Access 토큰의 유효 기간에 대한 적절한 조절이 필요함
자원 소유자 비밀번호 자격증명 승인 (Resource Owner Password Credentials Grant)	클라이언트 자격증명 승인 (Client Credentials Grant)
-클라이언트 유형 ·모든 클라이언트 유형 가능 ·일반적으로 API 제공 업체가 배포한 애플리케이션 -장기적 접근 ·Refresh 토큰을 통해 지원 -보안성 ·자원 소유자의 비밀번호가 애플리케이션에 노출되고, 피싱 위험이 존재 ·Access 토큰 발급 요청 시에만 비밀번호가 사용되기 때문에 클라이언트에 인증정보를 저장할 필요 없음	-클라이언트 유형 ·클라이언트가 데이터를 소유하고 있거나, 접근 위임이 이미 허용된 경우 -장기적 접근 ·Refresh 토큰 미지원 ·클라이언트 인증만으로 즉시 Access 토큰 재발급 가능 -보안성 ·클라이언트 인증만으로 Access 토큰을 발급하기 때문에 안전한 인증 방식 사용 및 인증 정보의 규칙적인 변경이 필요함

<권한 코드 승인 세부 내용>

단계	세부 내용
①단계	Client가 웹 브라우저에게 Redirect URI를 전달하여 권한 서버의 인증 및 권한 확인 웹 페이지로 redirection 시킴 · 권한 서버가 Client를 식별할 수 있도록 Client 정보 식별자에 해당하는 Client ID를 함께 전달
②단계	권한 서버의 자원 소유자(User)에 대한 인증 방식을 통해 인증 및 자원에 대한 접근 권한 승인 요청 · 일반적인 웹 서비스에서는 ID/PASSWORD 방식을 통해 User 인증
③단계	권한 서버는 웹 브라우저를 다시 Client에게로 redirection* 시키며, 이때 User로부터 보호된 자원에 대한 접근 권한을 승인 받았음을 나타내는 권한 코드를 Client에게 전달 * Client 등록 시, 권한 서버에 제출한 URI, 또는 ① 단계에서 전달한 Redirect URI 사용
④단계	Client는 Access 토큰을 요청하기 위해, 권한 코드와 함께 Client 인증을 위한 Client ID 및 Client Secret을 권한 서버에 전달
⑤단계	권한 서버는 Access 토큰을 Client에게 반환 · Access 토큰에 유효 기간이 존재하는 경우, 기간 만료까지 남은 시간 (expires_in)과 Refresh 토큰 정보도 함께 반환
Access 토큰 재발급	만약 Access 토큰의 유효 기간이 만료되어 재발급 받을 경우, 위 단계의 반복 없이 Refresh 토큰과 Client ID 및 Client Secret 으로 권한 서버에 재발급 요청

OAuth 2.0의 장점

• 자원 소유자(User)가 Client(myapp.com)에 비밀번호를 제공할 필요가 없으며, 피싱 등의 위협 감소
• myapp.com 개발자는 User의 비밀번호에 대한 안전한 저장 및 노출 위험성에 대해 걱정하지 않아도 됨
• User의 모든 권한이 아닌, myapp.com에게 반드시 필요한 권한만 제한적으로 제공 가능
• 보호된 자원에 대한 myapp.com의 접근을 각 Client별로 차단 및 권한 취소가 가능하며, 권한의 범위를 제어 가능
  • OAuth2.0방식이 아닌 비밀번호 방식의 경우, Client의 권한 취소를 위해서는 비밀번호를 변경해야하며,
    접근 권한을 재부여할 다른 Client에게 비밀번호 제공 필요
  • Client별 API 호출 가능 횟수 제한, 일부 자원에 대한 접근만 허용하는 등의 권한 범위 제어 가능

참조

금융보안원 - OAuth 2.0 개요 및 보안 고려사항