close
본문으로 이동

OAuth

위키백과, 우리 모두의 백과사전.
BERJAYA
크리스 메시나가 디자인한 비공식 로고
마지막 버전2.0
조직국제 인터넷 표준화 기구
웹사이트IETF OAuth Datatracker

OAuth("Open Authorization")[1][2]는 접근 위임을 위한 개방형 표준이다. 일반적으로 인터넷 사용자가 비밀번호를 제공하지 않고도 웹사이트나 애플리케이션이 다른 웹사이트에 있는 자신의 정보에 접근할 수 있도록 허용하는 방법으로 사용된다.[3][4] 이 메커니즘은 아마존[5], 구글, 메타 플랫폼스, 마이크로소프트, Twitter와 같은 기업에서 사용자가 자신의 계정 정보를 타사 애플리케이션이나 웹사이트와 공유할 수 있도록 하는 데 사용된다.

일반적으로 OAuth 프로토콜은 자원 소유자가 클라이언트 애플리케이션에 서버 자원에 대한 보안 위임 접근 권한을 제공하는 방법을 제공한다. 이는 자원 소유자가 자격 증명을 제공하지 않고도 제3자의 서버 자원 접근을 승인하는 과정을 명시한다. 특히 하이퍼텍스트 전송 프로토콜(HTTP)과 함께 작동하도록 설계된 OAuth는 본질적으로 자원 소유자의 승인을 받아 권한 부여 서버가 제3자 클라이언트에게 접근 토큰을 발행할 수 있게 한다. 그러면 제3자는 이 접근 토큰을 사용하여 자원 서버가 호스팅하는 보호된 자원에 접근한다.[2]

역사

[편집]
Authorization flow without Oauth.
로그인 정보가 제3자 애플리케이션과 공유되는 가상의 권한 부여 흐름. 이는 OAuth 권한 부여 흐름을 사용하여 방지할 수 있는 많은 보안 위험을 초래한다.
A high-level overview of Oauth 2.0 authorization flow.
OAuth 2.0 흐름에 대한 상위 수준 개요. 자원 소유자 자격 증명은 권한 부여 서버에서만 사용되며 클라이언트(예: 타사 앱)에서는 사용되지 않는다.

OAuth는 2006년 11월 블레인 쿡이 Twitter를 위한 오픈아이디 구현을 개발하면서 시작되었다. 한편, 매그놀리아는 오픈아이디를 가진 회원들이 맥 OS X 대시보드 위젯이 서비스에 접근하도록 승인할 수 있는 솔루션이 필요했다. 쿡, 매그놀리아의 크리스 메시나와 래리 핼프는 데이비드 레코돈과 만나 인증을 위임하기 위해 트위터와 매그놀리아 API에 오픈아이디를 사용하는 것에 대해 논의했다. 그들은 API 접근 위임을 위한 개방형 표준이 없다는 결론을 내렸다.[6]

2007년 4월, 소규모 구현 그룹이 개방형 프로토콜을 위한 초안 제안서를 작성할 수 있도록 OAuth 토론 그룹이 생성되었다. 구글의 드윗 클린턴은 OAuth 프로젝트에 대해 알게 되었고 이 노력을 지원하는 데 관심을 표명했다. 2007년 7월, 팀은 초기 사양을 초안으로 작성했다. 에란 해머가 합류하여 OAuth의 많은 기여를 조정하고 더욱 공식적인 사양을 만들었다. 2007년 10월 3일, OAuth Core 1.0 최종 초안이 발표되었다.[6]

2008년 11월 미니애폴리스에서 열린 제73회 국제 인터넷 표준화 기구(IETF) 회의에서 프로토콜을 IETF로 가져와 추가 표준화 작업을 논의하기 위한 OAuth BoF가 개최되었다. 이 행사는 많은 참석자가 모였으며 IETF 내에 OAuth 워킹 그룹을 공식적으로 구성하는 것에 대한 광범위한 지지가 있었다.

OAuth 1.0 프로토콜은 2010년 4월 정보성 Request for Comments인 RFC 5849로 발표되었다. 2010년 8월 31일부터 모든 타사 트위터 애플리케이션은 OAuth를 사용해야 했다.[7]

OAuth 2.0 프레임워크는 더 넓은 IETF 커뮤니티에서 수집된 추가적인 사용 사례 및 확장성 요구 사항을 고려하여 발표되었다. OAuth 1.0 배포 경험을 바탕으로 구축되었지만, OAuth 2.0은 OAuth 1.0과 하위 호환되지 않는다. OAuth 2.0은 RFC 6749로, Bearer Token Usage 사양은 RFC 6750으로 2012년 10월 표준 트랙 RFC로 각각 발표되었다.[2][8]

2024년 11월 기준으로 OAuth 2.1 Authorization Framework 초안이 진행 중이다. 이는 OAuth 2.0 RFC, 네이티브 앱을 위한 OAuth 2.0, 인증 코드 교환을 위한 증명 키(PKCE), 브라우저 기반 앱을 위한 OAuth 2.0, OAuth 보안 모범 사례 및 Bearer Token Usage의 기능을 통합한다.[9]

보안 문제

[편집]

OAuth 1.0

[편집]

2009년 4월 23일, 1.0 프로토콜의 세션 고정 보안 결함이 발표되었다. 이는 OAuth Core 1.0 섹션 6의 OAuth 권한 부여 흐름("3-legged OAuth"라고도 함)에 영향을 미친다.[10] 이 문제를 해결하기 위해 OAuth Core 프로토콜 버전 1.0a가 발행되었다.[11]

OAuth 2.0

[편집]

2013년 1월, 국제 인터넷 표준화 기구는 OAuth 2.0에 대한 위협 모델을 발표했다.[12] 개요된 위협 중 하나는 "Open Redirector"라고 불리는 것인데, 2014년 초 왕징(Wang Jing)에 의해 "Covert Redirect"라는 이름으로 변종이 설명되었다.[13][14][15][16]

OAuth 2.0은 공식 웹 프로토콜 분석을 사용하여 분석되었다. 이 분석은 다수의 권한 부여 서버가 있는 설정에서 그중 하나가 악의적으로 행동할 경우, 클라이언트가 사용할 권한 부여 서버에 대해 혼란을 겪고 악의적인 권한 부여 서버(AS Mix-Up Attack)로 비밀 정보를 전달할 수 있음을 밝혀냈다.[17] 이로 인해 OAuth 2.0에 대한 새로운 보안 표준을 정의하는 새로운 모범 사례 인터넷 초안이 작성되었다.[18] AS Mix-Up 공격에 대한 수정 사항이 적용된 것으로 가정할 때, OAuth 2.0의 보안은 공식 분석을 사용하여 강력한 공격자 모델 하에서 증명되었다.[17]

수많은 보안 결함이 있는 OAuth 2.0의 한 구현 사례가 노출되기도 했다.[19]

2017년 4월과 5월, 약 100만 명의 Gmail 사용자(2017년 5월 기준 사용자 전체의 0.1% 미만)가 OAuth 기반 피싱 공격의 표적이 되었으며, 동료, 고용주 또는 친구를 사칭하여 구글 문서(Google Docs)를 공유하려는 이메일을 받았다.[20] 이메일 내의 링크를 클릭한 사람들은 로그인을 요구받고 "Google Apps"라는 잠재적으로 악의적인 타사 프로그램이 자신의 "이메일 계정, 연락처 및 온라인 문서"에 접근하도록 허용하게 되었다.[20] "약 1시간" 이내에[20] 피싱 공격은 구글에 의해 중단되었으며, 구글은 "Google Apps"에 이메일 접근 권한을 부여한 사람들에게 해당 접근 권한을 취소하고 비밀번호를 변경할 것을 권고했다.

OAuth 2.1 초안에서는 악의적인 브라우저 확장 프로그램이 OAuth 2.0 코드 삽입 공격을 수행하지 못하도록 웹 애플리케이션 및 기타 기밀 클라이언트를 포함한 모든 종류의 OAuth 클라이언트에 네이티브 앱용 PKCE(RFC 7636) 확장 사용을 권장하고 있다.[9]

유형

[편집]

OAuth 프레임워크는 다양한 사용 사례에 대한 여러 권한 부여 유형을 명시한다. 가장 일반적인 OAuth 권한 부여 유형은 다음과 같다.[21]

  • Authorization Code (인증 코드)
  • PKCE
  • Client Credentials (클라이언트 자격 증명)
  • Device Code (기기 코드)
  • Refresh Token (갱신 토큰)
  • Resource Owner Password Credentials (ROPC, 자원 소유자 비밀번호 자격 증명)

용도

[편집]

페이스북의 그래프 API는 OAuth 2.0만 지원한다.[22] 구글은 모든 API에 대해 권장되는 권한 부여 메커니즘으로 OAuth 2.0을 지원한다.[23] 마이크로소프트 또한 다양한 API와 Azure Active Directory 서비스를 위해 OAuth 2.0을 지원하며[24], 이는 많은 마이크로소프트 및 타사 API를 보호하는 데 사용된다.

OAuth는 보안된 RSS/Atom 피드에 접근하기 위한 권한 부여 메커니즘으로 사용될 수 있다. 인증이 필요한 RSS/ATOM 피드에 대한 접근은 항상 문제였다. 예를 들어, 보안된 구글 사이트의 RSS 피드는 구글 리더를 사용하여 접근할 수 없었다. 대신, 해당 RSS 클라이언트가 구글 사이트의 피드에 접근할 수 있도록 승인하는 데 3-legged OAuth가 사용되었을 것이다.

리브레오피스 OAuth2OOo 확장 프로그램과 같은 OAuth2 프로토콜의 자유 소프트웨어 클라이언트 구현은 원격 자원(예: 구글 API 또는 마이크로소프트 그래프 API 및 OAuth 2.0을 통해)에 대한 접근을 허용하며, 심지어 리브레오피스 베이직 언어를 통해서도 가능할 수 있다. 이를 통해 리브레오피스 매크로에서 OAuth 2.0 프로토콜을 지원하는 HTTP 요청을 매우 쉽게 작성하고 사용할 수 있다.

OAuth와 다른 표준들

[편집]

OAuth는 오픈아이디를 보완하고 구별되는 서비스이다. OAuth는 인증을 위한 참조 아키텍처이지 권한 부여를 위한 표준이 아닌 OATH와는 관련이 없다. 그러나 OAuth는 오픈아이디 커넥트(OIDC)와는 직접적으로 관련이 있는데, OIDC가 OAuth 2.0 상에 구축된 인증 계층이기 때문이다. OAuth는 또한 권한 부여 정책 표준인 XACML과도 관련이 없다. OAuth는 XACML과 함께 사용할 수 있는데, OAuth는 소유권 동의 및 접근 위임에 사용되고, XACML은 권한 부여 정책을 정의하는 데 사용된다(예: 관리자는 해당 지역의 문서를 볼 수 있음).

오픈아이디 대 OAuth를 이용한 의사 인증

[편집]

OAuth는 인증 프로토콜이 아니라 권한 부여 프로토콜이다. OAuth만을 인증 방법으로 사용하는 것을 의사 인증(pseudo-authentication)이라고 부를 수 있다.[25] 다음 다이어그램은 (인증 프로토콜로 특별히 설계된) 오픈아이디를 사용하는 것과 권한 부여를 위해 OAuth를 사용하는 것 사이의 차이점을 강조한다.

두 프로세스의 통신 흐름은 유사하다.

  1. (그림 없음) 사용자가 애플리케이션에 자원 또는 사이트 로그인을 요청한다.
  2. 사이트는 사용자가 인증되지 않았음을 확인한다. 사이트는 ID 공급자를 위한 요청을 공식화하고, 이를 인코딩하여 리다이렉트 URL의 일부로 사용자에게 보낸다.
  3. 사용자의 브라우저가 애플리케이션의 요청을 포함하여 ID 공급자의 리다이렉트 URL로 요청을 보낸다.
  4. 필요한 경우, ID 공급자가 사용자를 인증한다(아마도 사용자 이름과 비밀번호를 요구함으로써).
  5. ID 공급자가 사용자가 충분히 인증되었다고 판단하면, 애플리케이션의 요청을 처리하고 응답을 공식화하여 리다이렉트 URL과 함께 사용자에게 다시 보낸다.
  6. 사용자의 브라우저가 ID 공급자의 응답을 포함하여 애플리케이션으로 돌아가는 리다이렉트 URL을 요청한다.
  7. 애플리케이션은 ID 공급자의 응답을 디코딩하고 이에 따라 진행한다.
  8. (OAuth만 해당) 응답에는 애플리케이션이 사용자 대신 ID 공급자의 서비스에 직접 접근하는 데 사용할 수 있는 접근 토큰이 포함된다.

결정적인 차이점은 오픈아이디 인증 사용 사례에서는 ID 공급자의 응답이 신원 증명인 반면, OAuth 권한 부여 사용 사례에서는 ID 공급자가 API 공급자이기도 하며 ID 공급자의 응답은 애플리케이션이 사용자 대신 일부 ID 공급자의 API에 지속적으로 접근할 수 있도록 허용하는 접근 토큰이라는 점이다. 접근 토큰은 애플리케이션이 ID 공급자에게 보내는 요청에 포함할 수 있는 일종의 "발렛 키" 역할을 하며, 이는 애플리케이션이 해당 API에 접근할 수 있는 사용자로부터의 권한을 가지고 있음을 증명한다.

ID 공급자는 일반적으로(항상 그런 것은 아니지만) OAuth 접근 토큰을 부여하는 과정의 일부로 사용자를 인증하기 때문에, 성공적인 OAuth 접근 토큰 요청을 인증 방법 그 자체로 보는 유혹이 있다. 그러나 OAuth는 이러한 사용 사례를 염두에 두고 설계되지 않았기 때문에, 이러한 가정을 하는 것은 주요 보안 결함으로 이어질 수 있다.[26]

오픈아이디 vs. OAuth를 이용한 의사 인증

OAuth와 XACML

[편집]

XACML은 정책 기반의 속성 기반 접근 제어 권한 부여 프레임워크이다. 이는 다음을 제공한다.

  • 접근 제어 아키텍처.
  • OAuth를 통해 처리/정의된 동의를 사용할 수 있는 정책을 포함하여 광범위한 접근 제어 정책을 표현할 수 있는 정책 언어.
  • 권한 부여 요청을 보내고 받는 요청/응답 체계.

XACML과 OAuth를 결합하여 더욱 포괄적인 권한 부여 접근 방식을 제공할 수 있다. OAuth는 접근 제어 정책을 정의할 수 있는 정책 언어를 제공하지 않는다. XACML은 그 정책 언어로 사용될 수 있다.

OAuth가 위임된 접근(사용자인 내가 트위터에게 페이스북 담벼락 접근 권한을 부여함)과 신원 중심의 권한 부여에 중점을 두는 반면, XACML은 사용자, 작업, 자원 및 컨텍스트(누가, 무엇을, 어디서, 언제, 어떻게)의 속성을 고려할 수 있는 속성 기반 접근 방식을 취한다. XACML을 사용하면 다음과 같은 정책을 정의할 수 있다.

  • 관리자는 부서 내 문서를 볼 수 있다.
  • 관리자는 초안 모드에서 자신이 소유한 문서를 편집할 수 있다.

XACML은 OAuth보다 더 세분화된 접근 제어를 제공한다. OAuth는 대상 서비스에 의해 노출되는 거친 기능(범위)에 대한 세분성으로 제한된다. 결과적으로, OAuth가 위임된 접근 사용 사례와 동의 관리를 제공하고, XACML이 애플리케이션, 프로세스 및 데이터에서 작동하는 권한 부여 정책을 제공하도록 OAuth와 XACML을 결합하는 것이 종종 합리적이다.

마지막으로, XACML은 여러 스택(API, 웹 SSO, ESB, 직접 만든 앱, 데이터베이스...)에서 투명하게 작동할 수 있다. OAuth는 HTTP 기반 앱에만 독점적으로 초점을 맞춘다.

논란

[편집]

에란 해머(Eran Hammer)는 2012년 7월 OAuth 2.0 프로젝트의 수석 저자직에서 사임하고, IETF 워킹 그룹에서 탈퇴했으며, 사양에서 자신의 이름을 삭제했다. 해머는 떠나는 이유로 웹 문화와 엔터프라이즈 문화 간의 갈등을 꼽으며, IETF가 "엔터프라이즈 사용 사례에 관한" 커뮤니티이지 "단순함을 위한" 커뮤니티가 아니라고 언급했다. 그는 "지금 제공되는 것은 엔터프라이즈 방식의 권한 부여 프로토콜 청사진"이며, 이는 "컨설팅 서비스와 통합 솔루션을 판매할 완전히 새로운 영역"을 제공한다고 지적했다.[27] OAuth 2.0과 OAuth 1.0을 비교하면서, 해머는 이것이 "더 복잡하고, 상호 운용성이 떨어지며, 덜 유용하고, 더 불완전하며, 무엇보다도 보안성이 떨어진다"고 지적했다. 그는 2.0을 위한 아키텍처 변경이 클라이언트로부터 토큰을 분리하고, 프로토콜 수준에서 모든 서명과 암호화를 제거했으며, 권한 부여 처리를 복잡하게 만들면서 만료되는 토큰을 추가한 방법을 설명했다. "이 워킹 그룹의 성격상, 너무 작아서 막히거나 각 구현이 결정하도록 남겨둘 수 없는 이슈는 없다"는 이유로 사양에서 수많은 항목이 명시되지 않거나 제한되지 않은 채로 남겨졌다.[27]

데이비드 레코돈도 나중에 불특정 이유로 사양에서 자신의 이름을 삭제했다. 딕 하트가 편집자 역할을 맡았고, 프레임워크는 2012년 10월에 발표되었다.[2]

이메일 클라이언트 페가수스 메일의 저자인 데이비드 해리스(David Harris)는 OAuth 2.0을 "완전한 엉망진창"이라고 비판하며, 개발자가 각 서비스(Gmail, 마이크로소프트 메일 서비스 등)에 특화된 사용자 지정 모듈을 작성하고, 해당 서비스에 구체적으로 등록해야 한다고 지적했다.[28]

같이 보기

[편집]

각주

[편집]
  1. ↑ “Open Authorization - Glossary | CSRC”. NIST Computer Security Resource Center. 2022년 9월 21일에 원본 문서에서 보존된 문서. 2021년 7월 23일에 확인함.
  2. 1 2 3 4 Hardt, Dick (October 2012). Hardt, D (편집). “RFC6749 - The OAuth 2.0 Authorization Framework”. 국제 인터넷 표준화 기구. doi:10.17487/RFC6749. 2012년 10월 15일에 원본 문서에서 보존된 문서. 2012년 10월 10일에 확인함.
  3. ↑ Whitson, Gordon. “Understanding OAuth: What Happens When You Log Into a Site with Google, X, or Facebook”. 《라이프해커》. 2014년 4월 24일에 원본 문서에서 보존된 문서. 2016년 5월 15일에 확인함.
  4. ↑ Henry, Gavin (January 2020). “Justin Richer on OAuth”. 《IEEE Software》 37 (1): 98–100. doi:10.1109/MS.2019.2949648. ISSN 0740-7459.
  5. ↑ “Amazon & OAuth 2.0”. 2017년 12월 8일에 원본 문서에서 보존된 문서. 2017년 12월 15일에 확인함.
  6. 1 2 “OAuth Introduction”. 2026년 4월 1일에 원본 문서에서 보존된 문서. 2026년 4월 1일에 확인함.
  7. ↑ Chris Crum (2010년 8월 31일). “Twitter Apps Go OAuth Today”. 《WebProNews》. 2017년 7월 31일에 원본 문서에서 보존된 문서. 2017년 7월 31일에 확인함.
  8. ↑ Jones, Michael; Hardt, Dick (October 2012). “RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage”. 국제 인터넷 표준화 기구. doi:10.17487/RFC6750. 2012년 10월 15일에 원본 문서에서 보존된 문서. 2012년 10월 10일에 확인함.
  9. 1 2 Lodderstedt, Torsten; Hardt, Dick; Parecki, Aaron (2024년 11월 15일). “The OAuth 2.1 Authorization Framework” (영어). tools.ietf.org. 2024년 12월 19일에 확인함.
  10. ↑ “OAuth Security Advisory: 2009.1”. 《OAuth Community Site》. 2009년 4월 23일. 2016년 5월 27일에 원본 문서에서 보존된 문서. 2009년 4월 23일에 확인함.
  11. ↑ “OAuth Core 1.0a”. 《OAuth Community Site》. 2009년 6월 30일에 원본 문서에서 보존된 문서. 2009년 7월 17일에 확인함.
  12. ↑ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (January 2013). Lodderstedt, T (편집). “RFC6819 - OAuth 2.0 Threat Model and Security Considerations” (영어). 《국제 인터넷 표준화 기구》. doi:10.17487/RFC6819. 2020년 6월 30일에 원본 문서에서 보존된 문서. 2020년 6월 29일에 확인함.[rfc:6819 OAuth 2.0 Threat Model and Security Considerations]. 국제 인터넷 표준화 기구. Accessed January 2015.
  13. ↑ “OAuth Security Advisory: 2014.1 "Covert Redirect"”. 《OAuth Community Site》. 2014년 5월 4일. 2015년 11월 21일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  14. ↑ “Serious security flaw in OAuth, OpenID discovered”. 《CNET》. 2014년 5월 2일. 2015년 11월 2일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  15. ↑ “Math student detects OAuth, OpenID security vulnerability”. Phys.org. 2014년 5월 3일. 2015년 11월 6일에 원본 문서에서 보존된 문서. 2014년 11월 11일에 확인함.
  16. ↑ “Covert Redirect”. Tetraph. 2014년 5월 1일. 2016년 3월 10일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  17. 1 2 Fett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). 〈A Comprehensive Formal Security Analysis of OAuth 2.0〉. 《Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security》. New York, New York, USA: ACM Press. 1204–1215쪽. arXiv:1601.01229. Bibcode:2016arXiv160101229F. doi:10.1145/2976749.2978385. ISBN 9781450341394. S2CID 1723789.
  18. ↑ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel (2019년 7월 8일). “OAuth 2.0 Security Best Current Practice” (영어). 《국제 인터넷 표준화 기구》. 2020년 1월 17일에 원본 문서에서 보존된 문서. 2019년 7월 29일에 확인함.
  19. ↑ “Hacking Facebook with OAuth 2.0 and Chrome”. 2013년 2월 12일. 2016년 4월 23일에 원본 문서에서 보존된 문서. 2013년 3월 6일에 확인함.
  20. 1 2 3 “Google Docs phishing email 'cost Minnesota $90,000'”. 《BBC 뉴스》. 2017년 5월 8일. 2020년 6월 30일에 원본 문서에서 보존된 문서. 2020년 6월 29일에 확인함.
  21. ↑ “Oauth Grant Types”. 《Oauth.net》. 2023년 12월 6일에 확인함.
  22. ↑ “Authentication - Facebook Developers”. 《Facebook for Developers》. 2014년 1월 23일에 원본 문서에서 보존된 문서. 2020년 1월 5일에 확인함.
  23. ↑ “Using OAuth 2.0 to Access Google APIs | Google Identity Platform”. 《Google Developers》. 2020년 1월 4일에 원본 문서에서 보존된 문서. 2020년 1월 4일에 확인함.
  24. ↑ “v2.0 Protocols - OAuth 2.0 Authorization Code Flow”. 《Microsoft Docs》. 2020년 6월 29일에 원본 문서에서 보존된 문서. 2020년 6월 29일에 확인함.
  25. ↑ “An Introduction to OAuth2 Authentication”. 《Akamai Connected Cloud》. 2021년 10월 22일. 2024년 4월 18일에 원본 문서에서 보존된 문서. 2024년 4월 18일에 확인함.
  26. ↑ “End User Authentication with OAuth 2.0”. 《OAuth Community Site》. 2015년 11월 19일에 원본 문서에서 보존된 문서. 2016년 3월 8일에 확인함.
  27. 1 2 Hammer, Eran (2012년 7월 28일). “OAuth 2.0 and the Road to Hell”. 《Hueniverse》. 2013년 3월 25일에 원본 문서에서 보존된 문서. 2018년 1월 17일에 확인함.
  28. ↑ Harris, David (October 2021). “October 2021 - Updates and reassurances”. 《Pegasus Mail》. 2024년 1월 16일에 원본 문서에서 보존된 문서. 2024년 12월 19일에 확인함.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=OAuth&oldid=42106084"