OAuth 란 무엇인가?
어떻게 시작해야 할까? 어떻게 설명해야 잘 설명할 수 있을까? 고민을 했다
우선 이전에 설명 했듯이 SSO는 서비스고, OAUTH는 규약(프로토콜) 이다
요식업 서비스에는 배송 규약(프로토콜)이 준비 되어있는 것처럼 말이다
SSO (서비스) 는 OAUTH (프로토콜) 방식을 이용해서 설계 되어질 수 있다
OAUTH (Open Standard for Authorization)
2006년 Twitter와 Google이 정의한 개방형 Authorization 표준이며, API 허가(Authorize)를 목적으로 JSON(JavaScript Object Notation) 형식으로 개발
사용자는 한 번의 인가 절차로 다른 웹 서비스를 이용할 때, 로그인 자격 증명 (예를 들면 단일 ID와 비밀번호)과 같은 개인정보를 전송하지 않고도 자신의 접근 또는 기타 권한을 부여 할 수 있도록 하는 것 (에 대한 공개 표준)
쇼핑몰 사이트에서 페이스북 아이디로 로그인 하면, 페이스북으로 사용자 접근권한 요청을 보내고, 사용자가 승인 할 경우, 사용자는 쇼핑몰을 이용할 수 있다. (우리가 흔히 알고 있는 사실)
개발자로서 OAUTH는 무엇인가? 에 집중 해보기 전에 역사(History)를 좀 알아보도록 하자
- OAuth 1.0
- RFC 5849: The OAuth 1.0 Protocol 에 정의 되어있다
- 세션 고정 공격 (a session fixation attack) 에 취약점이 발견되어 1.0a 개정판이 나오게 되었다 - OAuth 1.0 Revision A
- 1.0 spec의 세션 고정 공격을 해결하기 위해 만들어짐
- 1.0a 개정판을 만들었는데 2.0 인증 프레임워크가 나와 폐기됨;;; - OAuth 2.0
- RFC 6749 : The OAuth 2.0 Authorization Framework 에 정의
- 혼합 공격(Mix-Up Attack) 에 취약점 발견
- 많은 패치와 확장을 거쳐서 현재에 이르러 있다 - OAuth 2.1 (in-progress)
- 이름은 어떻게 바뀔지 모르지만 현재는 2.1로 IETF 에서 이야기 중
- 모든 인증 코드 부여에 대해 PKCE가 필요하다는게 중요 포인트
- legacy 들은 버릴 예정 (Implicit, Password Credentials )
- (2021. 12 기준) 아직 모든게 미정이지만, 계속 발전하는 중 이라는 것
현재 많이 사용중인 OAuth 2.0 Framework
다양한 클라이언트 환경에 적합한 인증(Authentication) 및 인가(Authorization) 의 부여(위임) 방법(Grant Type)을 제공하고 그 결과로 클라이언트에게 접근 토큰 (Access Token) 을 발급하는 것에 대한 구조(프레임워크) 이다
다양한 클라이언트 환경
스마트폰이 나오면서 모바일 기기에서 인터넷이 접근이 쉽게 되고, 2012년 이후로 웹과 모바일 환경은 극적으로 변화한다. 데스크톱 보다 모바일 장치에서 인터넷을 사용하는 사람들이 많아지고, 단일 페이지 앱 (SPA) 개발은 일반적인 방법으로 널리 통용되고, 수 많은 데이터베이스의 암호가 탈취되는 사건들로 인해서 암호를 저장하는 것이 위험하다는 것이 거듭 증명되고 있다
적합한 인증 및 인가 의 부여(위임) 방법(Grant Type)을 제공
변화하는 환경을 위해 OAuth 2.0 Framework 는 수 년에 걸친 패치와 사양들을 추가 했다 RFC6749는 Authorization Code, Implicit, Password, and Client Credentials 의 4가지의 권한 부여 방법을 진행할 수 있다
- Authorization Code
Web 혹은 Mobile App 에서 많이 사용한다
Access Token 을 위한 권한 인증 코드(Authorization Code)를 받을 때 사용하는 인증 - Implicit (Legacy)
Browser based App 이나 Mobile App 에서 많이 사용한다
권한 인증 코드(Authorization Code)없이 바로 Access Token 을 받는다 - Password (Legacy)
일반적인 아이디/비밀번호 입력 형태로 Access Token을 받는 방법
보통 자체 서비스에서만 사용되며, 외부 개발자가 사용할 수 없게 하는게 일반적이다 (비밀번호를 직접 입력하는 방법이라 보안 위배) - Client Credentials
사용자(User)가 아닌 Client(프로그램)을 인가(Authorization)가 필요할 때 사용하는 방법
결과로 클라이언트에게 접근 토큰(Access Token)을 발급
모두가 잘 알고 있는 JSON(Javascript Object Notation) 방식의 JWT (JSON Web Tokens)를 Access Token 형식으로 발급 받는다 (= 리턴 받는다)
Grant Type 의 변화
- Authorization Code
ImplicitResource Owner Password Credentials- Client Credentials
- PKCE
Mobile App에 더 나은 방법이 필요하다는 것이 분명 해졌고, Client Secret 없이 Authorization Code Flow을 사용할 수 있는 방법을 제공하기 위해 만들어짐
- PKCE for mobile
OAuth 2.0 for Native Apps : Native App이 PKCE 확장과 함께 Authorization Code Flow을 사용할 것을 권장
- Device Authorization Grant
Apple TV 또는 Youtube 스트리밍 비디오 인코더 같은 브라우저가 없거나 키보드가 없는 기기와 함께 OAuth를 사용해야 하는 상황이 생겼다. 이 문제를 해결하기 위해 완전히 새로운 OAuth Grant Type 이 생겨났다
결론적으로 2021년이 마무리 되는 때에는 아래 3가지 위임 방법(Grant Type)
- Authorization Code + PKCE
- Client Credentials
- Device Authorization
정도로 정리가 된다
만약 당신이 이제 OAUTH를 개발하고 사용한다면 Authorization Code + PKCE 형태를 사용하는것이 가장 현실적이고 합당한 방법이다
Client (프로그램)이 인증 받기를 원한다면 Client Credentials 를 사용하고,
특정 Device가 인증 받기를 위한다면 Device Authorization Grant 를 사용하면 된다
이것도 저것도 모를 때는 Authorization Code + PKCE 를 사용하는게 최고다 이 말이다!
PKCE 란 무엇인가?
Proof Key for Code Exchange by OAuth Public Clients
RFC7636 에 정의되어진 PKCE는 Authorization Code flow 의 확장팩이다 (PKCE, "pixy" - "픽시"로 발음)
Authorization Code Grant를 사용하는 OAuth 2.0 public client는 인증 코드 가로채기 공격(the authorization code interception attack)에 취약한데, 이 부분을 해결하기 위해 나온 방법이다 Code Exchange용 Proof Key를 통해 해당 공격에 대응한다.
말로는 자세히 모르겠지? 그래서 코드로 준비해 본다
다음 글에서 만나도록 하자
References
Contributors to Wikimedia projects
