OAuth

OAuth
미디어용Wiki(Wikipedia에서 사용하는 소프트웨어) OAuth 지원:도움말: OAuth

OAuth('오픈 인증')[1][2]는 인터넷 사용자가 다른 웹사이트의 정보에 대한 접근을 허용하지만 [3][4]비밀번호를 제공하지 않는 방법으로 일반적으로 사용되는 접근 위임의 개방형 표준입니다.이 메커니즘은 Amazon,[5] Google, Facebook, Microsoft 및 Twitter와 같은 회사에서 사용자가 자신의 계정에 대한 정보를 서드파티 애플리케이션 또는 웹사이트와 공유할 수 있도록 하기 위해 사용됩니다.

개요

일반적으로 OAuth는 자원 소유자를 대신하여 클라이언트에게 서버 리소스에 대한 "안전한 위임 액세스"를 제공합니다.리소스 소유자가 자격 증명을 제공하지 않고 서버 리소스에 대한 타사 액세스를 승인하는 프로세스를 지정합니다.HTTP(Hypertext Transfer Protocol)와 연동하도록 특별히 설계된 OAuth는 기본적으로 리소스 소유자의 승인을 받아 권한 서버에 의해 서드파티 클라이언트에 액세스 토큰을 발행할 수 있도록 합니다.그런 다음 타사에서는 액세스 토큰을 사용하여 리소스 [2]서버에서 호스팅하는 보호된 리소스에 액세스합니다.특히 OAuth 2.0은 웹 애플리케이션, 데스크톱응용 프로그램, 휴대전화 및 스마트디바이스에 대한 특정 인가 플로우를 제공합니다.

  • Authorization flow without Oauth.

    로그인 정보가 서드파티 어플리케이션과 공유되는 가상 인가 플로우.이로 인해 OAuth 인가 플로우를 사용함으로써 방지할 수 있는 많은 보안 리스크가 발생합니다.

  • A high-level overview of Oauth 2.0 authorization flow.

    Oauth 2.0 흐름의 개요.리소스 소유자 자격 증명은 권한 부여 서버에서만 사용되며 클라이언트(예: 타사 앱)에서는 사용되지 않습니다.

역사

미국 블로거 Chris Messina가 디자인한 OAuth 로고

OAuth는 Blaine Cook이 Twitter Open을 개발하던 2006년 11월에 시작되었습니다.ID의 실장.한편, Ma.gnolia는 회원들에게 Open을 허용하기 위한 솔루션이 필요했다.대시보드 위젯이 해당 서비스에 액세스할 수 있도록 인증하는 ID입니다.Magnolia의 Cook, Chris Messina 및 Larry Halff는 Open 사용을 논의하기 위해 David Recordon을 만났습니다.인증을 위임하기 위한 Twitter 및 Magnolia API를 사용하는 ID.그들은 API 액세스 [6]위임을 위한 개방형 표준이 없다고 결론지었다.

OAuth 토론 그룹은 소규모 구현자 그룹이 개방형 프로토콜 초안을 작성하기 위해 2007년 4월에 만들어졌다.구글의 드윗 클린턴은 OAuth 프로젝트에 대해 알게 되었고, 그 노력을 지원하는 것에 관심을 표명했다.2007년 7월에, 팀은 최초의 사양서의 초안을 작성했습니다.Eran Hammer는 많은 OAuth 기여에 동참하여 보다 공식적인 사양을 작성했습니다.2007년 12월 4일 OAuth Core 1.0 최종 드래프트가 [7]발표되었습니다.

2008년 11월 미니애폴리스에서 열린 제73회 인터넷 엔지니어링 태스크포스(IETF) 회의에서 OAuth BoF가 개최되어 추가 표준화 작업을 위해 프로토콜을 IETF에 도입하는 것을 논의했습니다.이 행사는 많은 사람들이 참석했으며 IETF 내에서 OAuth 작업 그룹을 공식적으로 차용하는 것에 대한 폭넓은 지지가 있었다.

OAuth 1.0 프로토콜은 RFC 5849로 2010년 4월에 공개되었습니다.2010년 8월 31일부터 모든 서드파티 트위터 애플리케이션은 OAuth를 [8]사용해야 합니다.

OAuth 2.0 프레임워크는 더 넓은 IETF 커뮤니티에서 수집된 추가 사용 사례 및 확장성 요구사항을 고려하여 발행되었습니다.OAuth 2.0은 OAuth 1.0 도입 경험을 기반으로 구축되어 있지만 OAuth 2.0과 하위 호환성은 없습니다.OAuth 2.0은 RFC 6749로, 베어러 토큰 사용량은 RFC 6750으로 공개되었으며,[2][9] 두 표준 모두 2012년 10월에 코멘트 요청을 추적합니다.

OAuth 2.1 인가 프레임워크는 드래프트 단계에 있으며 RFC OAuth 2.0, OAuth 2.0, OAuth 2.0, 코드 교환용 Proof Key, 브라우저 기반 애플리케이션용 OAuth 2.0, OAuth 토큰 및 현재 최선의 보안 기능을 통합하고 있습니다.

보안 문제

OAuth 1.0

2009년 4월 23일 1.0 프로토콜의 세션 고정 보안 결함이 발표되었습니다.OAuth Core 1.0 섹션6의 [11]OAuth 허가 플로우(일명 '3레그 OAuth')에 영향을 줍니다.이 [12]문제를 해결하기 위해 OAuth 코어 프로토콜 버전 1.0a가 발행되었습니다.

OAuth 2.0

2013년 1월, Internet Engineering Task Force는 OAuth 2.[13]0의 위협 모델을 발표했습니다.개괄적인 위협으로는 "오픈 리다이렉터"라고 불리는 것이 있습니다.2014년 초, Wang [14][15][16][17]Jing에 의해 "커버트 리다이렉트"라는 이름으로 설명되었습니다.

OAuth 2.0은 정식 웹 프로토콜 분석을 사용하여 분석되었습니다.이 분석 결과, 복수의 인가 서버가 있는 셋업에서는, 그 중 하나가 악의적으로 동작하고 있는 경우, 클라이언트는 사용하는 인가 서버에 대해서 혼란을 일으켜, 그 악의 있는 인가 서버에 비밀 정보를 전송 할 가능성이 있는 것이 밝혀졌습니다(AS 믹스 [18]업 공격).이에 따라 OAuth 2.0의 [19]새로운 보안 표준을 정의하는 새로운 베스트 프랙티스 인터넷 초안이 작성되었습니다.AS Mix-Up 공격에 대한 수정이 이루어지고 있다고 가정하면 OAuth 2.0의 보안은 정식 [18]분석을 사용하는 강력한 공격자 모델에서 증명됩니다.

OAuth 2.0의 실장 중 다수의 보안 [20]결함이 있는 것이 판명되었습니다.

2017년 4월과 5월, 약 100만 명의 Gmail 사용자(2017년 5월 현재 사용자 중 0.1퍼센트 미만)가 OAuth 기반 피싱 공격의 표적이 되었고, 구글 [21]독스에서 문서를 공유하려는 동료, 고용주 또는 친구로부터 이메일을 받았다.전자 메일 내의 링크를 클릭한 사용자는 로그인하여 잠재적으로 악의적인 서드파티 프로그램인 "Google Apps"가 자신의 "전자 메일 계정, 연락처 및 온라인 문서"[21]에 액세스할 수 있도록 허용하도록 지시받았습니다."약 1시간"[21] 이내에, 피싱 공격은 구글에 의해 중단되었고, 구글 앱스(Google Apps)"에 대한 액세스 권한을 부여한 사람들에게 이러한 액세스를 취소하고 암호를 변경하라고 권고했다.

OAuth 2.1 초안에서는 OAuth 2.0 코드 주입 [10]공격을 실행하는 악의적인 브라우저 확장을 방지하기 위해 웹 애플리케이션 및 기타 기밀 클라이언트를 포함한 모든 종류의 OAuth 클라이언트에 PKCE 확장 사용을 권장하고 있습니다.

사용하다

페이스북의 Graph API는 OAuth 2.0만 지원합니다.[22]구글은 모든 [23]API에 대해 OAuth 2.0을 권장 인증 메커니즘으로 지원합니다.마이크로소프트는 또한 다양한 API에 대한 OAuth 2.0과 다수의 마이크로소프트 및 서드파티 API를 보호하기 위해 사용되는 Azure Active Directory [24]서비스를 지원합니다.

OAuth는 안전한 RSS/Atom 피드에 액세스하기 위한 인증 메커니즘으로 사용할 수 있습니다.인증이 필요한 RSS/ATOM 피드에 대한 액세스는 항상 문제가 되어 왔습니다.예를 들어, 보안된 Google 사이트의 RSS 피드는 Google Reader를 사용하여 액세스할 수 없습니다.대신 RSS 클라이언트가 Google 사이트에서 피드에 액세스할 수 있도록 하기 위해 3개의 다리를 가진 OAuth가 사용되었습니다.

OAuth 및 기타 표준

OAuth는 Open을 보완하는 서비스이며 Open과는 구별됩니다.ID. OAuth는 인증 기준이 아닌 인증 참조 아키텍처인 OAuth와 관련이 없습니다.단, OAuth는 Open과 직접 관련되어 있습니다.OIDC는 OAuth 2.0 위에 구축된 인증 레이어이기 때문에 ID Connect(OIDC).OAuth는 인가 정책 표준인 XACML과도 관련이 없습니다.OAuth는 XACML과 함께 사용할 수 있습니다.여기서 OAuth는 소유권 동의 및 접근 위임을 위해 사용되는 반면 XACML은 권한 정책을 정의하는 데 사용됩니다(예를 들어 관리자는 해당 지역의 문서를 볼 수 있습니다).

OAuth를 사용한 OpenID와 유사 인증

OAuth는 인증 프로토콜이 아닌 인증 프로토콜입니다.인증 방식으로서 OAuth 자체를 사용하는 것을 의사 [citation needed]인증이라고 부릅니다.다음 그림에서는 Open을 사용하는 경우의 차이를 보여 줍니다.인증 프로토콜로 특별히 설계된 ID 및 OAuth.

양쪽 프로세스의 통신 흐름은 비슷합니다.

  1. (그림 없음)사용자가 응용 프로그램에서 리소스 또는 사이트 로그인을 요청합니다.
  2. 사이트에는 사용자가 인증되지 않은 것으로 표시됩니다.ID 프로바이더에 대한 요구를 공식화하고 이를 부호화하여 리다이렉트 URL의 일부로 사용자에게 전송합니다.
  3. 사용자의 브라우저가 응용 프로그램의 요청을 포함하여 ID 제공자의 리디렉션 URL에 요청을 합니다.
  4. 필요에 따라서, ID 프로바이더는 유저를 인증합니다(유저명과 패스워드의 입력을 요구할 가능성이 있습니다).
  5. 사용자가 충분히 인증되었다고 판단되면 ID 공급자는 응용 프로그램의 요청을 처리하고 응답을 작성하여 응용 프로그램으로 리다이렉트 URL과 함께 사용자에게 반환합니다.
  6. 사용자의 브라우저가 ID 제공자의 응답을 포함하여 애플리케이션으로 돌아가는 리디렉션 URL을 요청합니다.
  7. 응용 프로그램은 ID 제공자의 응답을 해독하고 그에 따라 작업을 수행합니다.
  8. (OAuth만)응답에는 사용자 대신 애플리케이션이 ID 제공자의 서비스에 직접 액세스하는 데 사용할 수 있는 액세스 토큰이 포함됩니다.

중요한 차이점은 오픈에서ID 인증 사용 사례에서는 ID 제공자의 응답이 ID의 어설션입니다.OAuth 인증 사용 사례에서는 ID 제공자도 API 제공자이며 ID 제공자의 응답은 사용자의 API 중 일부에 대한 지속적인 액세스를 애플리케이션에 부여할 수 있는 액세스 토큰입니다.이익.액세스 토큰은 어플리케이션이 ID 프로바이더에 대한 요구와 함께 포함할 수 있는 일종의 "밸릿 키" 역할을 합니다.이것에 의해, 유저가 이러한 API에 액세스 할 수 있는 권한을 가지고 있는 것이 증명됩니다.

일반적으로 ID 프로바이더는 OAuth 액세스토큰 부여 프로세스의 일부로 사용자를 인증하기 때문에 성공한 OAuth 액세스토큰 요구를 인증 방식 자체로서 보는 것이 바람직합니다.그러나 OAuth는 이 사용 사례를 염두에 두고 설계되지 않았기 때문에 이러한 가정을 하면 심각한 보안 [25]결함이 발생할 수 있습니다.

OpenID vs. pseudo-authentication using OAuth

OAuth 및 XACML

XACML은 정책 기반의 Atribute 기반 접근컨트롤 인가 프레임워크입니다다음과 같은 기능이 있습니다.

  • 액세스 컨트롤 아키텍처
  • OAuth를 통해 처리되거나 정의된 동의를 사용할 수 있는 정책을 포함하여 광범위한 액세스 제어 정책을 표현하기 위한 정책 언어입니다.
  • 권한 부여 요청을 송수신하는 요청/응답 체계입니다.

XACML과 OAuth를 조합하여 보다 포괄적인 인증 방식을 제공할 수 있습니다.OAuth에서는 액세스컨트롤 정책을 정의하는 데 사용하는 정책 언어는 제공되지 않습니다.XACML은 정책 언어에 사용할 수 있습니다.

OAuth가 위임된 액세스(I, 사용자, Facebook 벽에 대한 Twitter 액세스 허용) 및 ID 중심의 인증에 초점을 맞춘 경우 XACML은 사용자, 액션, 리소스 및 컨텍스트(누가, 무엇을, 어디서, 언제, 어떻게)의 속성을 고려할 수 있는 속성 기반 접근 방식을 취합니다.XACML 에서는, 다음과 같은 정책을 정의할 수 있습니다.

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

XACML은 OAuth보다 세밀한 접근컨트롤을 제공합니다.OAuth는 타깃서비스에 의해 공개되는 저속기능(스코프)으로 입도가 제한됩니다.그 결과 OAuth와 XACML을 함께 결합하는 것이 적절할 수 있습니다.OAuth는 위임된 액세스 사용 사례와 동의 관리를 제공하고 XACML은 애플리케이션, 프로세스 및 데이터에 대해 작동하는 인증 정책을 제공합니다.

마지막으로 XACML은 여러 스택(API, 웹 SSO, ESB, 자체 개발한 애플리케이션, 데이터베이스 등)에서 투과적으로 작동합니다.OAuth는 HTTP 기반 앱에만 초점을 맞춥니다.

논란

Eran Hammer는 OAuth 2.0 프로젝트의 수석 작성자 역할에서 사임하고 IETF 워킹 그룹에서 탈퇴하고 2012년 7월에 사양서에서 이름을 삭제했습니다.Hammer는 탈퇴의 이유로 웹과 기업 문화 간의 충돌을 들며 IETF는 "엔터프라이즈 사용 사례에 관한 모든 것"이며 "단순하지 못한" 커뮤니티임을 지적했습니다."현재 제공되는 것은 인증 프로토콜의 청사진입니다."라고 그는 언급하며 "그것이 엔터프라이즈 방식입니다."라고 말하며 "컨설팅 서비스와 통합 [26]솔루션을 판매하는 새로운 개척지"를 제공합니다.OAuth 2.0과 OAuth 1.0을 비교하면서 Hammer는 OAuth 2.0이 "더 복잡해지고, 상호 운용성이 떨어지고, 유용성이 떨어지고, 불완전하고, 가장 중요한 것은 보안성이 저하되었다"고 지적합니다.그는 클라이언트의 2.0 바인딩되지 않은 토큰에 대한 아키텍처 변경, 프로토콜 수준에서 모든 서명 및 암호화 제거, 만료 토큰 추가(토큰을 해지할 수 없었기 때문에) 권한 부여 처리를 복잡하게 만드는 방법을 설명합니다.「이 작업 그룹의 성질대로, 각 실장이 결정할 수 있도록, 또는 미해결 상태로 둘 수 있는 작은 문제는 없습니다.」 때문에, 사양에는 미지정 또는 무제한의 항목이 다수 남아 있었습니다."[26]

David Recordon도 나중에 특정되지 않은 [citation needed]이유로 그의 이름을 명세서에서 삭제했다.Dick Hardt가 편집자 역할을 이어받아 2012년 [2]10월에 프레임워크가 발행되었습니다.

E-메일 클라이언트 Pegasus Mail의 저자 David Harris는 OAuth 2.0을 "절대 개의 아침 식사"라고 비판하고 개발자는 각 서비스(Gmail, Microsoft Mail 등)에 고유한 커스텀 모듈을 작성하고 [27]이에 등록해야 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Open Authorization - Glossary CSRC". csrc.nist.gov.
  2. ^ a b c d Hardt, Dick (October 2012). "RFC6749 - The OAuth 2.0 Authorization Framework". Internet Engineering Task Force. Archived from the original on 15 October 2012. Retrieved 10 October 2012.
  3. ^ Whitson, Gordon. "Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook". Lifehacker. Archived from the original on 24 April 2014. Retrieved 15 May 2016.
  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". Archived from the original on 8 December 2017. Retrieved 15 December 2017.
  6. ^ "Introduction". oauth.net. Archived from the original on 21 November 2018. Retrieved 21 November 2018.
  7. ^ "OAuth Core 1.0". 4 December 2007. Archived from the original on 25 November 2015. Retrieved 16 October 2014.
  8. ^ Chris Crum (31 August 2010). "Twitter Apps Go OAuth Today". WebProNews.com. Archived from the original on 31 July 2017. Retrieved 31 July 2017.
  9. ^ Jones, Michael; Hardt, Dick (October 2012). "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Internet Engineering Task Force. Archived from the original on 15 October 2012. Retrieved 10 October 2012.
  10. ^ a b Lodderstedt, Torsten; Hardt, Dick; Parecki, Aaron. "The OAuth 2.1 Authorization Framework". tools.ietf.org. Retrieved 22 November 2020.
  11. ^ "OAuth Security Advisory: 2009.1". oauth.net. 23 April 2009. Archived from the original on 27 May 2016. Retrieved 23 April 2009.
  12. ^ "OAuth Core 1.0a". oauth.net. Archived from the original on 30 June 2009. Retrieved 17 July 2009.
  13. ^ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (January 2013). "RFC6819 - OAuth 2.0 Threat Model and Security Considerations". Internet Engineering Task Force. Archived from the original on 30 June 2020. Retrieved 29 June 2020.[rfc:6819 OAuth 2.0 위협 모델 및 보안 고려사항]인터넷 기술 특별 조사단2015년 1월에 액세스.
  14. ^ "OAuth Security Advisory: 2014.1 "Covert Redirect"". oauth.net. 4 May 2014. Archived from the original on 21 November 2015. Retrieved 10 November 2014.
  15. ^ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 May 2014. Archived from the original on 2 November 2015. Retrieved 10 November 2014.
  16. ^ "Math student detects OAuth, OpenID security vulnerability". Phys.org. 3 May 2014. Archived from the original on 6 November 2015. Retrieved 11 November 2014.
  17. ^ "Covert Redirect". Tetraph. 1 May 2014. Archived from the original on 10 March 2016. Retrieved 10 November 2014.
  18. ^ a b 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 - CCS'16. New York, New York, USA: ACM Press: 1204–1215. arXiv:1601.01229. Bibcode:2016arXiv160101229F. doi:10.1145/2976749.2978385. ISBN 9781450341394. S2CID 1723789.
  19. ^ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel. "OAuth 2.0 Security Best Current Practice". Internet Engineering Task Force. Archived from the original on 17 January 2020. Retrieved 29 July 2019.
  20. ^ "Hacking Facebook with OAuth 2.0 and Chrome". 12 February 2013. Archived from the original on 23 April 2016. Retrieved 6 March 2013.
  21. ^ a b c "Google Docs phishing email 'cost Minnesota $90,000'". BBC News. 8 May 2017. Archived from the original on 30 June 2020. Retrieved 29 June 2020.
  22. ^ "Authentication - Facebook Developers". Facebook for Developers. Archived from the original on 23 January 2014. Retrieved 5 January 2020.
  23. ^ "Using OAuth 2.0 to Access Google APIs Google Identity Platform". Google Developers. Archived from the original on 4 January 2020. Retrieved 4 January 2020.
  24. ^ "v2.0 Protocols - OAuth 2.0 Authorization Code Flow". Microsoft Docs. Archived from the original on 29 June 2020. Retrieved 29 June 2020.
  25. ^ "End User Authentication with OAuth 2.0". oauth.net. Archived from the original on 19 November 2015. Retrieved 8 March 2016.
  26. ^ a b Hammer, Eran (28 July 2012). "OAuth 2.0 and the Road to Hell". Hueniverse. Archived from the original on 25 March 2013. Retrieved 17 January 2018.
  27. ^ Harris, David (October 2021). "Pegasus Mail and Mercury Developer News". Pegasus Mail.

외부 링크