OAuth
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
OAuth는 API 접근 권한을 위임하기 위한 개방형 표준 프로토콜이다. 2007년 OAuth 1.0이 발표되었으며, 2012년 OAuth 2.0이 출시되었고, 2024년 OAuth 2.1 초안이 진행 중이다. OAuth는 사용자, 소비자, 서비스 제공자 간의 상호 작용을 통해 작동하며, 액세스 토큰을 사용하여 보호된 리소스에 접근한다. OAuth는 페이스북, 구글, 마이크로소프트 등에서 활용되며, OpenID Connect와 관련이 있지만, 인증이 아닌 인가를 위한 프로토콜이다. OAuth는 XACML과 함께 사용하여 권한 부여에 대한 포괄적인 접근 방식을 제공할 수 있다.
더 읽어볼만한 페이지
- 컴퓨터 접근 제어 프로토콜 - RADIUS
RADIUS는 네트워크 접근 관리에 사용되는 AAA 프로토콜로, 클라이언트-서버 모델을 기반으로 사용자 인증 및 권한 부여를 수행하며 다양한 환경에서 활용된다. - 컴퓨터 접근 제어 프로토콜 - Z-Wave
Z-Wave는 1999년 덴마크에서 개발된 홈 오토메이션 프로토콜로, 900MHz 비허가 주파수를 사용하며, 메시 네트워크를 통해 최대 232개의 장치를 연결하고 S2 보안 기능을 제공하며 스마트 홈 분야에서 널리 사용된다. - 컴퓨터 접근 제어 - 로그인
로그인은 특정 페이지, 웹사이트 또는 응용 프로그램에 접근하기 위해 사용자 이름과 암호를 입력하여 시스템에 접근하는 절차이며, 1960년대 시분할 시스템과 1970년대 BBS에서 사용되기 시작했다. - 컴퓨터 접근 제어 - SIM 카드
SIM 카드는 이동통신 장치에서 가입자 정보를 저장하고 네트워크를 인증하는 스마트 카드로, 가입자 식별 정보, 인증 정보, 전화번호부 등을 저장하며, 최근에는 내장형 eSIM으로 발전하고 있다. - 인터넷 프로토콜 - IPTV
IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다. - 인터넷 프로토콜 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
| OAuth | |
|---|---|
| 개요 | |
| 이름 | OAuth (오어스) |
| 종류 | 인가를 위한 개방형 표준 |
| 개발 | IETF |
| 최신 버전 | 2.0 |
| 참고 문서 | RFC 6749 RFC 6750 |
| 상세 정보 | |
| 설명 | OAuth는 웹사이트나 애플리케이션이 사용자 이름과 비밀번호를 공유하지 않고도 다른 웹사이트에 저장된 정보에 접근할 수 있는 권한을 부여하는 개방형 표준 인가 프로토콜임. |
| 작동 방식 | OAuth는 리소스 소유자(사용자)가 클라이언트 애플리케이션에 리소스 서버(API 제공자)에 대한 제한된 접근 권한을 부여할 수 있도록 허용함. |
| 주요 특징 | 사용자 이름과 비밀번호를 공유하지 않고도 안전하게 접근 권한을 위임 가능 다양한 클라이언트 애플리케이션 및 리소스 서버 지원 접근 토큰을 사용하여 권한 관리 |
| 사용 사례 | 사용자가 자신의 소셜 미디어 계정을 다른 애플리케이션과 연동 애플리케이션이 사용자 대신 API에 접근하여 데이터를 가져오거나 업데이트 |
| 기술 | |
| 기반 기술 | HTTP TLS JSON |
| 관련 표준 | OpenID Connect SAML |
| 역사 | |
| 최초 개발 | 2007년 |
| 표준화 | IETF를 통해 표준화됨 |
2. 역사
OAuth가 등장하기 전에는 인증 방식에 대한 표준이 없어, 아이디와 비밀번호를 이용한 기본 인증 방식이 주로 사용되었으나 이는 보안에 취약했다. 또는 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth 등 각 기업이 개발한 독자적인 인증 방식을 사용해야 했다. 매시업 등 웹 서비스 간 연계가 증가하면서 디지털 아이덴티티 공유 문제가 중요해졌고, OpenID와 같은 연합 아이덴티티 기술이 등장했지만 이는 사용자를 인증하는 수단일 뿐, 특정 자원에 대한 접근 인가까지 다루지는 못했다. 이에 따라 웹 서비스 API 접근을 안전하게 인가할 표준화된 방식의 필요성이 커졌다.
OAuth는 이러한 배경 속에서 제각각이었던 인증 방식을 표준화하기 위해 등장했다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요 없어 통합적인 서비스 사용이 가능해진다.
OAuth 개발은 2006년 11월 블레인 쿡이 트위터에 OpenID를 구현하던 중 API 접근 위임 표준의 필요성을 인지하면서 시작되었다.[6] 개발자 커뮤니티 결성과 구글 등의 지원을 통해 2007년 OAuth Core 1.0 최종 초안이 발표되었고,[7][53] 인터넷 기술 특별 기동대(IETF)에서의 논의를 거쳐 2010년 4월, OAuth 1.0 프로토콜이 공식 표준안(
OAuth 1.0의 경험을 바탕으로 더 넓은 사용 사례와 확장성 요구를 반영한 OAuth 2.0 프레임워크가 개발되었다. OAuth 2.0은 OAuth 1.0과 하위 호환되지 않으며, 2012년 10월 핵심 프레임워크(
2024년 11월 현재, 이전 버전들의 기능을 통합하고 최신 보안 권장 사항을 반영하는 OAuth 2.1 권한 부여 프레임워크 초안 작업이 진행 중이다.[10]
2. 1. OAuth 1.0
2006년 11월, 블레인 쿡은 트위터에 OpenID를 구현하는 작업을 진행하고 있었다. 동시에 소셜 북마크 사이트인 Ma.gnolia는 회원들이 OpenID를 사용하여 대시보드 위젯 같은 서비스에 접근할 수 있도록 인증 권한을 부여하는 방법이 필요했다. 이에 쿡, 크리스 메시나, 래리 하프(Ma.gnolia)는 데이비드 레코든(베리사인)과 만나 OpenID를 활용해 트위터나 Ma.gnolia의 API 인증을 위임하는 방안을 논의했다. 이 과정에서 그들은 API 접근 위임에 대한 공개 표준이 아직 없다는 결론에 도달했다.[6]OAuth 개발을 위한 인터넷 커뮤니티(토론 그룹)는 2007년 4월에 시작되었고, 소수의 개발자들이 모여 새로운 공개 프로토콜의 초안을 작성했다. 구글의 드위트 클린턴은 이 프로젝트를 알게 된 후 지원 의사를 밝혔다. 2007년 7월, 팀은 초기 사양 초안을 완성했으며, 이후 에런 해머가 합류하여 여러 기여자의 의견을 조율하며 더 공식적인 사양을 만들어 나갔다. 2007년 12월 4일, OAuth 코어 1.0 최종 초안이 발표되었다.[7][53]
2008년 11월, 미니애폴리스에서 열린 제73회 인터넷 기술 특별 기동대(IETF) 회의에서는 OAuth에 대한 비공식 회의(BoF)가 열렸다. 이 자리에서는 OAuth 프로토콜을 IETF 내에서 표준화 작업으로 진행할지 여부가 논의되었고, 참석자들의 폭넓은 지지를 얻어 IETF 내에 공식 OAuth 워킹 그룹을 설립하는 발판을 마련했다.
2010년 4월, OAuth 1.0 프로토콜은 IETF에 의해 정보성 의견 요청(RFC) 문서인
그러나 2009년 4월 23일, OAuth 1.0 프로토콜에서 세션 고정 관련 보안 결함이 발견되었다. 이 문제는 특히 OAuth 코어 1.0 사양의 섹션 6에 기술된 인증 흐름(소위 "3자 인증 OAuth")에 영향을 미쳤다.[11][43] 이 보안 문제를 해결하기 위해 OAuth 코어 1.0a 버전이 발표되었다.[12]
2. 2. OAuth 2.0
OAuth 2.0 프레임워크는 OAuth 1.0 이후 광범위한 인터넷 기술 특별 기동대(IETF) 커뮤니티에서 수집된 추가 사용 사례 및 확장성 요구 사항을 고려하여 개발되었다. OAuth 1.0 배포 경험을 바탕으로 구축되었지만, OAuth 2.0은 OAuth 1.0과 하위 호환되지 않는다. 이는 클라이언트가 되는 웹 애플리케이션, 데스크톱 애플리케이션, 스마트폰, 리빙 디바이스 등 다양한 애플리케이션 개발자에게 리소스 접근 권한을 부여하는 간편한 방법을 제공하는 것을 목표로 한다.[44]
OAuth 2.0 사양은 2012년 8월 RFC 편집자에게 송부되었으며, 중심이 되는 "The OAuth 2.0 Authorization Framework"는 RFC 6749로,[46] Bearer 토큰 사용 사양은 RFC 6750으로 2012년 10월에 게시되었다.[2][9][47]
주요 기업들도 OAuth 2.0을 도입하기 시작했다. 페이스북의 Graph API는 OAuth 2.0 Draft 10을 지원하며 초기 대규모 구현 사례 중 하나가 되었다.[48] 2011년 기준으로 구글[49]과 마이크로소프트[50]도 OAuth 2.0을 실험적으로 도입하여 API를 제공했다.
그러나 OAuth 2.0과 관련하여 여러 보안 문제가 제기되었다. 2013년 1월, IETF는 OAuth 2.0에 대한 위협 모델을 발표했다.[13] 이 중 "Open Redirector"라는 위협이 제시되었고, 2014년 초에는 왕징(Wang Jing)이 이의 변종인 "Covert Redirect"를 설명했다.[14][15][16][17] 또한, 공식 웹 프로토콜 분석을 통해 여러 인증 서버 중 하나가 악의적일 경우 클라이언트가 사용할 인증 서버를 혼동하여 비밀 정보를 악의적인 서버로 전송할 수 있는 "AS Mix-Up Attack"이 발견되었다.[18] 이러한 문제점들은 OAuth 2.0의 새로운 보안 표준을 정의하기 위한 현재 최선의 실례(Best Current Practice) 인터넷 초안 작업으로 이어졌다.[19] AS Mix-Up Attack에 대한 수정이 적용된다는 가정 하에, OAuth 2.0의 보안은 강력한 공격자 모델 하에서 공식 분석을 통해 입증되었다.[18] 그럼에도 불구하고 보안 결함이 있는 OAuth 2.0 구현 사례들이 노출되기도 했다.[20]
2017년 4월과 5월에는 약 100만 명의 Gmail 사용자(당시 전체 사용자의 0.1% 미만)가 OAuth 기반 피싱 공격의 대상이 되었다. 사용자들은 동료나 친구로부터 Google Docs 문서 공유 요청처럼 보이는 이메일을 받았고,[21] 이메일 내 링크를 클릭하면 "Google Apps"라는 악성 프로그램에 이메일 계정, 연락처 등에 대한 접근 권한을 부여하도록 유도되었다.[21] 구글은 약 1시간 내에 이 공격을 중단시키고, 피해 사용자들에게 접근 권한 철회 및 비밀번호 변경을 권고했다.[21]
이러한 보안 문제에 대응하고 기능을 개선하기 위해 OAuth 2.1 권한 부여 프레임워크 초안 작업이 진행 중이다(2024년 11월 기준). OAuth 2.1은 기존 RFC OAuth 2.0, 네이티브 앱용 OAuth 2.0, 코드 교환용 증명 키(PKCE), 브라우저 기반 앱용 OAuth 2.0, OAuth 보안 최신 정보, Bearer 토큰 사용 등의 기능을 통합한다.[10] 특히, 악의적인 브라우저 확장에 의한 코드 삽입 공격을 방지하기 위해 네이티브 앱뿐만 아니라 웹 애플리케이션 등 모든 종류의 OAuth 클라이언트에 RFC 7636 확장(PKCE) 사용을 권장하고 있다.[10]
3. 용어
OAuth가 사용되기 전에는 인증 방식의 표준이 없어 기존의 아이디와 비밀번호를 이용한 기본 인증 방식이 주로 사용되었으나, 이는 보안상 취약할 수 있다. 일부 애플리케이션들은 각자 개발한 방식으로 사용자를 확인하기도 했는데, 예를 들어 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있었다.
OAuth는 이렇게 다양한 인증 방식을 표준화한 방식으로, OAuth를 이용하면 인증 정보를 공유하는 애플리케이션 간에는 별도의 추가 인증 없이 통합하여 사용하는 것이 가능하다.
OAuth와 관련된 기본적인 용어는 다음과 같다.
| 용어 | 설명 |
|---|---|
| 사용자 (user) | 서비스 제공자와 소비자를 사용하는 계정을 가진 개인 |
| 소비자 (consumer) | Open API를 이용하여 개발되었으며, OAuth를 통해 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션 |
| 서비스 제공자 (service provider) | OAuth를 통한 접근을 지원하는 웹 애플리케이션 (Open API를 제공하는 서비스) |
| 소비자 비밀번호 (consumer secret) | 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키 |
| 요청 토큰 (request token) | 소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보가 담겨 있으며, 후에 접근 토큰으로 변환된다. |
| 접근 토큰 (access token) | 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값. |
3. 1. OAuth 2.0의 역할
OAuth 2.0에서는 다음과 같은 4가지 종류의 역할(롤)을 정의한다.[31]| 역할 | 설명 |
|---|---|
| 리소스 소유자 (resource owner) | 보호된 리소스에 대한 접근 권한을 부여하는 주체이다. 리소스 소유자가 사람인 경우에는 최종 사용자(end-user)라고도 부른다. |
| 리소스 서버 (resource server) | 보호된 리소스를 호스팅하는 서버이다. 예를 들어, 사용자의 사진을 보관하는 서비스의 서버가 이에 해당한다. |
| 클라이언트 (client) | 리소스 소유자를 대신하여 보호된 리소스에 접근하는 애플리케이션이다. 예를 들어, 사진 인쇄 서비스 애플리케이션이 클라이언트가 될 수 있다. |
| 인가 서버 (authorization server) | 리소스 소유자를 인증하고 클라이언트에게 접근 토큰(Access Token)을 발급하는 서버이다. 리소스 서버와 동일한 서버일 수도 있고, 별도의 서버일 수도 있다.[31] |
이 4가지 역할을 구체적인 예시를 들어 설명하면 다음과 같다. 어떤 사용자(리소스 소유자)가 웹사이트 A(리소스 서버)에 계정을 가지고 있고, A에 보관된 자신의 사진(리소스)을 다른 웹사이트 B(클라이언트)의 인쇄 서비스를 이용하여 인쇄하고 싶다고 가정해 보자. 이 경우 사용자는 사이트 B에게 "사이트 A에 보관된 자신의 사진에 접근하여 인쇄할 수 있는 권한"을 부여(인가)해야 한다.
이때 사용자는 사이트 A가 신뢰하는 인가 서버를 통해 인증을 받는다. 인증이 완료되면 인가 서버는 사이트 B가 사진 접근 및 인쇄 작업을 수행할 수 있도록 허용하는 접근 토큰(access token, 권한 위임용 자격 증명이라고도 함)을 발급하여 사용자에게 전달하고, 사용자는 이 토큰을 사이트 B에 넘겨준다. 이후 사이트 B는 필요할 때마다 이 접근 토큰을 사이트 A에 제시하여 사용자의 사진에 접근하고 인쇄 작업을 수행할 수 있게 된다.
이 과정에서 중요한 점은 사용자가 사이트 A의 비밀번호를 사이트 B에 직접 제공하지 않는다는 것이다. 단순히 사이트 A의 비밀번호를 사이트 B에 알려주는 방법으로도 권한을 줄 수 있지만, 이는 사진 인쇄에 필요하지 않은 다른 모든 권한까지 사이트 B에 넘겨주는 위험한 방식이다. OAuth는 이러한 단순한 방법의 단점을 보완하여, 필요한 최소한의 권한만을 안전하게 위임할 수 있도록 설계된 프로토콜이다.
다만, 사이트 A의 계정과 사이트 B의 계정이 연결되는 과정에서 보안 위험이 발생할 가능성은 여전히 존재한다.
3. 2. 액세스 토큰 (OAuth 2.0)
OAuth 2.0의 '''액세스 토큰'''(Access Token영어)은 보호된 리소스에 대한 접근 인가를 표현하는 문자열이다. 다시 말해, 액세스 토큰은 인가 자격 증명이다.[32]OAuth 2.0에서는 리소스 소유자가 인가 범위와 기간이 연결된 액세스 토큰을 클라이언트에 부여하고,[33] 클라이언트는 이를 사용하여 리소스에 접근한다. 리소스 서버는 인가 자격 증명인 액세스 토큰을 확인하여 접근을 제어하고, 정당한 요청에 리소스를 반환한다. 이처럼 액세스 토큰은 인가 프레임워크인 OAuth 2.0의 핵심 개념이다.
액세스 토큰 방식에는 보안상의 이점이 있다. 계정 비밀번호 인증으로 인가를 수행하는 경우, 자격 증명 유출은 비밀번호 유출 그 자체이며 계정 탈취로 직결될 수 있다. 반면 액세스 토큰은 제한적인 인가 정보만을 가지므로, 악의적인 클라이언트나 자격 증명 유출이 일으키는 악영향을 최소한(인가된 리소스에 대한 부정한 접근)으로 제한할 수 있다.
액세스 토큰의 내용, 형식, 전달 방법은 OAuth 2.0에서 규정되지 않으며, 각 리소스 서버가 해당 보안 요건에 따라 정의할 수 있다.[34] 액세스 토큰의 실례로서, 은닉된 임의 문자열이나 서명된 검증 가능 인가 정보(JWT)를 들 수 있다.[35] 또한, 인가 검증에 추가 자격 증명이 필요한지 여부(즉, 액세스 토큰 단독으로 필요 충분한지 여부)는 OAuth 사양의 범위를 벗어난다(PoP 토큰 등 관련 개념 참조).[36]
3. 3. 인가 부여 (OAuth 2.0)
OAuth 2.0의 '''인가 부여'''(Authorization Granteng)는 리소스 소유자의 인가를 나타내며 액세스 토큰 발급을 가능하게 하는 자격 증명이다.[37]쉽게 말해 "소유자의 인가를 나타내는 액세스 토큰 교환권"이 인가 부여이다. 인가 서버에서 이 권한을 실제 액세스 토큰으로 교환하는 단계를 거친다.
OAuth 2.0에서는 4가지 종류의 인가 부여 유형을 정의하고 있다. 다음은 그 목록이다.
4. 인증 방식 (OAuth 1.0)
OAuth 인증은 소비자와 서비스 제공자 사이에서 일어나는데, 이 인증 과정은 다음과 같다.[54]
# 소비자가 서비스 제공자에게 요청 토큰을 요청한다.
# 서비스 제공자가 소비자에게 요청 토큰을 발급해준다.
# 소비자가 사용자를 서비스 제공자로 이동시킨다. 여기서 사용자 인증이 수행된다.
# 서비스 제공자가 사용자를 소비자로 이동시킨다.
# 소비자가 접근 토큰을 요청한다.
# 서비스 제공자가 접근 토큰을 발급한다.
# 발급된 접근 토큰을 이용하여 소비자에서 사용자 정보에 접근한다.
5. 프로토콜 (OAuth 2.0)
OAuth 2.0의 프로토콜 흐름은 다음과 같다[41]:
# '''(A) 인증 요청 (Authorization Request):''' 클라이언트가 리소스 소유자(사용자)에게 인증을 요청한다. 인증 서버를 통해 간접적으로 요청하는 것이 권장된다.[41]
# '''(B) 인증 그랜트 (Authorization Grant):''' 리소스 소유자가 인증 요청을 승인하면, 인증 서버를 통해 클라이언트에게 '''인증 그랜트'''를 전달한다.[41]
# '''(C) 액세스 토큰 요청 (Access Token Request):''' 클라이언트는 전달받은 인증 그랜트를 인증 서버에 제시하며 액세스 토큰 발급을 요청한다.
# '''(D) 액세스 토큰 발급 (Access Token Issuance):''' 인증 서버는 클라이언트 인증 정보와 인증 그랜트의 유효성을 검증한 후, 문제가 없으면 액세스 토큰을 발급한다.
# '''(E) 리소스 접근 요청 (Resource Access Request):''' 클라이언트는 발급받은 액세스 토큰을 이용하여 리소스 서버에 보호된 리소스 접근을 요청한다.
# '''(F) 리소스 전달 (Resource Delivery):''' 리소스 서버는 액세스 토큰의 유효성을 확인하고, 유효하다면 클라이언트에게 요청한 리소스를 전달한다.
인증 그랜트를 발급하는 방식에는 다음 네 가지 유형이 있다[42]:
- '''인증 코드 (Authorization Code):''' 클라이언트는 리소스 소유자를 인증 서버로 리다이렉션하고, 인증 서버는 리소스 소유자를 인증한 후 인증 코드형 인증 그랜트를 발행한다.
- '''임플리시트 (Implicit):''' 자바스크립트 등 스크립트 언어를 사용하여 브라우저 상에서 실행되는 클라이언트를 위해 인증 코드를 최적화한 방식이다.
- '''리소스 오너 비밀번호 자격 증명 (Resource Owner Password Credentials):''' 리소스 소유자의 아이디와 비밀번호 같은 자격 증명을 클라이언트가 직접 받아 액세스 토큰으로 교환하는 방식이다.
- '''클라이언트 자격 증명 (Client Credentials):''' 클라이언트 자신이 관리하는 리소스나 인증 서버와 사전에 협의된 특정 리소스에 접근할 때 사용하는 방식으로, 인증 범위가 해당 리소스로 제한된다.
6. 보안 문제
2009년4월 23일, OAuth 1.0 프로토콜에서 세션 고정 관련 보안 결함이 발표되었다. 이는 OAuth Core 1.0 섹션 6의 OAuth 인증 흐름(일명 "3자 인증 OAuth")에 영향을 미쳤다.[11][43] OAuth Core 프로토콜의 버전 1.0a가 이 문제를 해결하기 위해 발행되었다.[12]
2013년 1월, IETF는 OAuth 2.0에 대한 위협 모델을 발표했다.[13] 제시된 위협 중에는 "Open Redirector"라는 것이 있는데, 2014년 초, 왕징(Wang Jing)은 이의 변종을 "Covert Redirect"라는 이름으로 설명했다.[14][15][16][17]
OAuth 2.0은 공식 웹 프로토콜 분석을 사용하여 분석되었다. 이 분석을 통해 여러 인증 서버(AS, Authorization Server)가 설정되어 있고 그중 하나가 악의적으로 동작하는 경우, 클라이언트는 사용할 인증 서버에 대해 혼란을 겪고 비밀 정보를 악의적인 인증 서버(AS Mix-Up Attack)로 전달할 수 있다는 사실이 밝혀졌다.[18] 이는 OAuth 2.0에 대한 새로운 보안 표준을 정의하기 위해 새로운 현재 최선의 실례 인터넷 초안을 만드는 계기가 되었다.[19] AS Mix-Up Attack에 대한 수정 사항이 적용되었다고 가정하면, OAuth 2.0의 보안은 강력한 공격자 모델 하에서 공식 분석을 사용하여 입증되었다.[18]
수많은 보안 결함이 있는 OAuth 2.0의 구현이 노출되었다.[20]
2017년 4월과 5월에 약 100만 명의 Gmail 사용자(2017년 5월 기준 0.1% 미만)가 OAuth 기반 피싱 공격의 대상이 되었으며, 동료, 고용주 또는 친구가 Google Docs에서 문서를 공유하고 싶다는 내용의 이메일을 받았다.[21] 이 이메일 내 링크를 클릭한 사용자는 로그인하여 "Google Apps"라는 잠재적으로 악의적인 타사 프로그램이 "이메일 계정, 연락처 및 온라인 문서"에 접근하도록 허용하라는 메시지를 받았다.[21] "약 1시간" 이내에,[21] 구글은 피싱 공격을 중단했으며, "Google Apps"에 이메일 접근 권한을 부여한 사용자에게 해당 접근 권한을 철회하고 비밀번호를 변경하도록 권고했다.
OAuth 2.1 초안에서는 악의적인 브라우저 확장이 OAuth 2.0 코드 삽입 공격을 수행하는 것을 방지하기 위해 모든 종류의 OAuth 클라이언트, 웹 애플리케이션 및 기타 기밀 클라이언트를 포함하여 네이티브 앱에 PKCE (RFC 7636) 확장 사용을 권장하고 있다.[10]
7. 활용
OAuth는 다양한 서비스에서 안전하게 사용자 인증을 처리하고 API 접근 권한을 부여하는 표준 방식으로 널리 활용된다. 페이스북(Facebook)의 Graph API는 OAuth 2.0만 지원하며,[23] 구글(Google) 역시 모든 API에 대해 OAuth 2.0을 권장 인증 메커니즘으로 지원한다.[24] 마이크로소프트(Microsoft)도 다양한 자체 API 및 타사 API 보호에 사용되는 Azure Active Directory 서비스 등에서 OAuth 2.0을 지원한다.[25]
또한 OAuth는 보호된 RSS나 Atom 피드 접근을 위한 인증 메커니즘으로 사용될 수 있다. 과거에는 인증이 필요한 RSS/Atom 피드 접근에 어려움이 있었으나, OAuth를 통해 RSS 클라이언트가 구글 사이트의 보호된 피드 등에 접근하도록 인증하는 것이 가능하다.
LibreOffice에서는 https://prrvchr.github.io/OAuth2OOo/ OAuth2OOo 확장과 같은 자유 소프트웨어 클라이언트 구현을 통해 구글 API나 마이크로소프트 그래프 API 등 OAuth 2.0으로 보호되는 원격 리소스에 접근할 수 있다. 이는 LibreOffice 매크로 등에서도 OAuth 2.0 기반의 HTTP 요청을 쉽게 작성하고 활용할 수 있게 한다.
8. 다른 표준과의 관계
OAuth는 다른 표준들과 다음과 같은 관계를 맺고 있다.
- '''OpenID''': OAuth는 인가(Authorization)를 위한 프로토콜이고 OpenID는 인증(Authentication)을 위한 프로토콜이라는 점에서 서로 구별된다. 두 표준은 상호 보완적인 관계에 있다. 자세한 내용은 OpenID와 OAuth 섹션에서 다룬다.
- '''OATH''': 이름이 유사하지만, OAuth는 권한 부여 참조 아키텍처인 OATH와는 관련이 없다.
- '''OpenID Connect (OIDC)''': OpenID Connect는 OAuth 2.0 프로토콜 위에 구축된 인증 계층으로, OAuth와 직접적인 관련이 있다.
- '''XACML''': XACML은 권한 부여 정책을 위한 표준으로 OAuth와 직접적인 관련은 없으나, 함께 사용될 수 있다. OAuth가 사용자 동의와 접근 위임을 처리하고 XACML이 세부적인 권한 부여 정책(예: 관리자는 해당 지역의 문서를 볼 수 있음)을 정의하는 데 사용될 수 있다. 자세한 내용은 OAuth와 XACML 섹션에서 다룬다.
8. 1. OpenID와 OAuth
OAuth는 '인가(Authorization)' 프로토콜이며, 사용자가 누구인지를 확인하는 '인증(Authentication)' 프로토콜이 아니다. 이 점에서 OpenID와는 다르다. OAuth를 인증 방법으로 단독으로 사용하는 것은 가짜 인증으로 간주될 수 있다.[26] 다음 다이어그램은 인증 프로토콜로 특별히 설계된 OpenID와 인가에 OAuth를 사용하는 것의 차이점을 보여준다.
두 프로세스의 통신 흐름은 다음과 같이 유사하다.
# (그림에 없음) 사용자는 애플리케이션에서 리소스 또는 사이트 로그인을 요청한다.
# 사이트는 사용자가 인증되지 않았음을 확인한다. 사용자는 ID 제공자에 대한 요청을 공식화하고, 이를 인코딩하여 리디렉션 URL의 일부로 사용자에게 보낸다.
# 사용자의 브라우저는 애플리케이션의 요청을 포함하여 ID 제공자에 대한 리디렉션 URL에 요청을 보낸다.
# 필요한 경우 ID 제공자는 사용자를 인증한다(예: 사용자에게 사용자 이름과 비밀번호를 묻는 방식).
# ID 제공자가 사용자가 충분히 인증되었다고 판단하면 애플리케이션의 요청을 처리하고, 응답을 공식화하여 애플리케이션으로 다시 리디렉션되는 URL과 함께 사용자에게 보낸다.
# 사용자의 브라우저는 ID 제공자의 응답을 포함하여 애플리케이션으로 다시 가는 리디렉션 URL을 요청한다.
# 애플리케이션은 ID 제공자의 응답을 디코딩하고 그에 따라 진행한다.
# (OAuth만 해당) 응답에는 애플리케이션이 사용자를 대신하여 ID 제공자의 서비스에 직접 접근하는 데 사용할 수 있는 액세스 토큰이 포함되어 있다.
가장 중요한 차이점은 OpenID ''인증'' 사용 사례에서 ID 제공자의 응답은 신원 주장인 반면, OAuth ''인가'' 사용 사례에서는 ID 제공자가 API 제공자이기도 하며, ID 제공자의 응답은 액세스 토큰이라는 점이다. 이 액세스 토큰은 애플리케이션이 사용자를 대신하여 ID 제공자의 특정 API에 지속적으로 접근할 수 있는 권한을 부여한다. 액세스 토큰은 애플리케이션이 ID 제공자에 대한 요청에 포함할 수 있는 일종의 "대리 열쇠" 역할을 하며, 사용자가 해당 API에 접근할 권한이 있음을 증명한다.
ID 제공자는 일반적으로 OAuth 액세스 토큰을 부여하는 과정의 일부로 사용자를 인증하기 때문에, 성공적인 OAuth 액세스 토큰 요청을 인증 자체로 간주하려는 경향이 있다. 그러나 OAuth는 이러한 인증 목적을 염두에 두고 설계되지 않았으므로, 이러한 방식으로 사용하는 것은 심각한 보안 결함을 초래할 수 있다.[27]
8. 2. OAuth와 XACML
OAuth는 권한 부여를 위한 서비스로, 인증을 위한 표준인 OpenID와는 구별되며, 권한 부여 참조 아키텍처인 OATH와도 관련이 없다. 다만, OAuth 2.0 위에 구축된 인증 계층인 OpenID Connect (OIDC)와는 직접적인 관련이 있다.또한 OAuth는 권한 부여 정책 표준인 XACML과도 직접적인 관련은 없다. 하지만 OAuth와 XACML은 함께 사용될 수 있는데, 이 경우 OAuth는 사용자의 동의를 얻고 접근 권한을 위임하는 데 사용되고, XACML은 구체적인 권한 부여 정책(예: "관리자는 자신이 속한 지역의 문서만 볼 수 있다")을 정의하는 데 사용된다.
XACML은 정책에 기반한 속성 기반 접근 제어(Attribute-Based Access Control, ABAC) 권한 부여 프레임워크이다. XACML은 다음과 같은 주요 기능을 제공한다.
- 접근 제어 아키텍처
- OAuth를 통해 처리되거나 정의된 동의를 활용하는 정책을 포함하여, 광범위한 접근 제어 정책을 표현할 수 있는 정책 언어
- 권한 부여 요청과 응답을 주고받기 위한 요청/응답 규격
OAuth와 XACML을 결합하면 권한 부여에 대해 더 포괄적인 접근 방식을 제공할 수 있다. OAuth 자체는 접근 제어 정책을 정의하는 정책 언어를 제공하지 않기 때문에, XACML을 정책 언어로 활용할 수 있다.
OAuth는 주로 위임된 접근(예: 사용자가 트위터 앱에게 자신의 페이스북 담벼락 접근 권한을 부여하는 것)과 ID 중심의 권한 부여에 초점을 맞춘다. 반면, XACML은 사용자의 속성, 행동, 접근하려는 자원, 그리고 접근 상황(누가, 무엇을, 어디서, 언제, 어떻게) 등 다양한 속성을 고려하는 방식을 사용한다. XACML을 사용하면 다음과 같은 구체적인 정책을 정의할 수 있다.
- 관리자는 자신이 속한 부서의 문서만 볼 수 있다.
- 관리자는 자신이 소유한 문서가 초안 상태일 때만 편집할 수 있다.
이처럼 XACML은 OAuth보다 더 세밀한 단위의 접근 제어를 가능하게 한다. OAuth의 접근 제어 단위는 대상 서비스가 제공하는 기능(범위, scope)에 따라 다소 큰 단위로 제한되는 경향이 있다. 따라서 OAuth가 위임된 접근 관리와 사용자 동의 관리를 담당하고, XACML이 애플리케이션, 프로세스, 데이터 수준에서 작동하는 세밀한 권한 부여 정책을 제공하는 방식으로 두 기술을 함께 사용하는 것이 효과적이다.
마지막으로, XACML은 API, 웹 SSO, ESB, 자체 개발 애플리케이션, 데이터베이스 등 다양한 기술 환경에서 투명하게 작동할 수 있다. 반면 OAuth는 주로 HTTP 기반의 웹 애플리케이션에 초점을 맞춘다.
9. 논란
2012년 7월, OAuth 2.0 프로젝트의 주 저자였던 에란 해머는 프로젝트에서 사임하고 IETF 워킹 그룹에서 탈퇴했으며, 명세서에서 자신의 이름을 삭제했다.[28] 해머는 웹 문화와 기업 문화 간의 갈등을 사임 이유로 들면서, IETF가 "모두 기업 사용 사례에 관한" 커뮤니티이며 "단순함을 감당할 수 없다"고 지적했다. 그는 "현재 제공되는 것은 '기업 방식'의 인증 프로토콜 청사진"이라며, 이는 "컨설팅 서비스 및 통합 솔루션을 판매할 수 있는 완전히 새로운 영역"을 제공한다고 언급했다.[28]
해머는 OAuth 2.0과 OAuth 1.0을 비교하면서, 2.0 버전이 "더 복잡해지고, 상호 운용성이 떨어지고, 덜 유용하고, 더 불완전하며, 가장 중요한 것은 덜 안전해졌다"고 비판했다.[28] 그는 2.0의 아키텍처 변경으로 인해 토큰이 클라이언트에서 분리되고, 프로토콜 수준에서 모든 서명 및 암호화가 제거되었으며, 토큰 만료 기능이 추가되었지만(토큰을 회수할 수 없기 때문에), 인증 처리 과정이 복잡해졌다고 설명했다. 또한, "이 워킹 그룹의 특성상, 각 구현에서 결정하도록 남겨두거나 막히는 데 너무 작은 문제는 없다"는 이유로 명세서에서 수많은 항목이 명시되지 않거나 제한 없이 남겨졌다고 지적했다.[28]
데이비드 레코드 역시 명확한 이유는 알려지지 않았으나 나중에 명세서에서 자신의 이름을 삭제했다.
이메일 클라이언트 페가수스 메일의 개발자인 데이비드 해리스는 OAuth 2.0을 "완전히 엉망진창"이라고 비판하며, 개발자가 Gmail, 마이크로소프트 메일 서비스 등 각 서비스에 특정한 맞춤형 모듈을 작성하고, 해당 서비스에 개별적으로 등록해야 하는 불편함을 지적했다.[29]
참조
[1]
웹사이트
Open Authorization - Glossary {{!}} CSRC
https://csrc.nist.go[...]
NIST Computer Security Resource Center
[2]
웹사이트
RFC6749 - The OAuth 2.0 Authorization Framework
https://tools.ietf.o[...]
Internet Engineering Task Force
2012-10-10
[3]
웹사이트
Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook
http://lifehacker.co[...]
2016-05-15
[4]
간행물
Justin Richer on OAuth
2020-01
[5]
웹사이트
Amazon & OAuth 2.0
https://login.amazon[...]
2017-12-15
[6]
웹사이트
Introduction
https://oauth.net/ab[...]
2018-11-21
[7]
웹사이트
OAuth Core 1.0
http://oauth.net/cor[...]
2014-10-16
[8]
웹사이트
Twitter Apps Go OAuth Today
http://www.webpronew[...]
2017-07-31
[9]
웹사이트
RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
https://tools.ietf.o[...]
Internet Engineering Task Force
2012-10-10
[10]
웹사이트
The OAuth 2.1 Authorization Framework
https://datatracker.[...]
tools.ietf.org
2024-11-15
[11]
웹사이트
OAuth Security Advisory: 2009.1
http://oauth.net/adv[...]
2009-04-23
[12]
웹사이트
OAuth Core 1.0a
http://oauth.net/cor[...]
2009-07-17
[13]
웹사이트
RFC6819 - OAuth 2.0 Threat Model and Security Considerations
https://tools.ietf.o[...]
2020-06-29
[14]
웹사이트
OAuth Security Advisory: 2014.1 "Covert Redirect"
http://oauth.net/adv[...]
2014-11-10
[15]
웹사이트
Serious security flaw in OAuth, OpenID discovered
http://www.cnet.com/[...]
2014-11-10
[16]
웹사이트
Math student detects OAuth, OpenID security vulnerability
http://phys.org/news[...]
Phys.org
2014-11-11
[17]
웹사이트
Covert Redirect
http://tetraph.com/c[...]
Tetraph
2014-11-10
[18]
서적
Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security
ACM Press
2016
[19]
웹사이트
OAuth 2.0 Security Best Current Practice
https://tools.ietf.o[...]
2019-07-08
[20]
웹사이트
Hacking Facebook with OAuth 2.0 and Chrome
http://homakov.blogs[...]
2013-03-06
[21]
웹사이트
Google Docs phishing email 'cost Minnesota $90,000'
https://www.bbc.co.u[...]
2020-06-29
[22]
웹사이트
Oauth Grant Types
https://oauth.net/2/[...]
2023-12-06
[23]
웹사이트
Authentication - Facebook Developers
https://developers.f[...]
2020-01-05
[24]
웹사이트
Using OAuth 2.0 to Access Google APIs | Google Identity Platform
https://developers.g[...]
2020-01-04
[25]
웹사이트
v2.0 Protocols - OAuth 2.0 Authorization Code Flow
https://docs.microso[...]
2020-06-29
[26]
웹사이트
An Introduction to OAuth2 Authentication
https://www.linode.c[...]
2024-04-18
[27]
웹사이트
End User Authentication with OAuth 2.0
http://oauth.net/art[...]
2016-03-08
[28]
웹사이트
OAuth 2.0 and the Road to Hell
https://hueniverse.c[...]
2018-01-17
[29]
웹사이트
October 2021 - Updates and reassurances
https://www.pmail.co[...]
2024-12-19
[30]
웹사이트
For immediate release: OAuth Core 1.0 Specification released at Internet Identity Workshop
http://blog.oauth.ne[...]
2024-01-15
[31]
문서
IETF RFC|6749日本語訳 1.1節
[32]
인용
[33]
인용
[34]
인용
[35]
인용
[36]
인용
RFC6749
[37]
인용
RFC6749
[38]
인용
RFC6749
[39]
인용
RFC6749
[40]
인용
RFC6749
[41]
문서
RFC6749일본어역 1.2절
[42]
문서
RFC6749일본어역 1.3절
[43]
웹사이트
OAuth Security Advisory: 2009.1
http://oauth.net/adv[...]
2009-04-23
[44]
웹사이트
The OAuth 2.0 Authorization Protocol
http://tools.ietf.or[...]
2011-02-16
[45]
웹사이트
Introducing OAuth 2.0
http://hueniverse.co[...]
2010-05-15
[46]
웹사이트
Dick Hardt, Ed. "The OAuth 2.0 Authorization Framework"
https://datatracker.[...]
[47]
웹사이트
Michael B. Jones, Dick Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage"
https://datatracker.[...]
[48]
웹사이트
Authentication - Facebook Developers
http://developers.fa[...]
[49]
웹사이트
Making auth easier: OAuth 2.0 for Google APIs
https://googlecode.b[...]
2011-03-14
[50]
웹사이트
Announcing Support for OAuth 2.0
http://windowsteambl[...]
2011-05-04
[51]
웹인용
Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook
http://lifehacker.co[...]
[52]
Amazon
Amazon & OAuth 2.0
https://login.amazon[...]
[53]
웹인용
OAuth Core 1.0
http://oauth.net/cor[...]
2007-12-04
[54]
이미지
http://oauth.net/cor[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com