버그헌팅 #2 웹 기본

 

웹은 크게 위의 개념으로 설명할 수 있다. 사용자 요청을 받는 부분을 프론트 엔드, 요청을 처리하는 부분을 백엔드라고 한다. 프론트 엔드는 사용자에게 보여지는 부분으로써, 웹 리소스인 자원들로 이뤄진다. 웹 리소스에는 폰트, 이미지, 크기, 색상 등이 관련 언어로 작성되어 있다. 우리가 흔히 404 NOT FOUND라는 오류를 접할 수 있는데, 여기서 찾지 못했다는 의미의 NOT FOUND는 정확히는 자원을 찾지 못했다는 의미다.

 

리소스에는 크게 HTML, CSS, JS가 있다. HTML은 웹 문서의 뼈대를 담당한다. CSS는 웹 문서의 생김새를 담당하는, 시각화 방법을 기재한 시트라 할 수 있다. 글자, 배경, 이미지, 위치, 색상 등을 지정하는 것이다. 마지막으로 자바 스크립트는 웹 문서의 동작 방법을 정의한다. 마우스로 클릭을 했을 때, 스크롤을 했을 때 어떻게 반응할지, 데이터를 입력하면 어디로 전송할지 등을 자바 스크립트로 구현하는 것이다.

 

웹은 크게 클라인트 사이드 취약점과 서버 사이드 취약점으로 나뉘는데, 클라이언트 사이드 취약점을 파악하기 위해서는 HTML과 자바스크립트를 학습하는 것이 중요하다.

 

웹 리소스는 모두 URI를 갖고 식별되는데, URI는 인터넷에서 자원을 고유하게 식별하고 위치를 지정할 수 있는 문자열이다. 웹에서 사용되는 주소체계를 기반으로 한다. 여기서 URI와 URL의 차이점은 URL은 단순히 URI의 하위집합이라는 점이다. 

 

이제 URI의 각 파트에 대해 학습하도록 한다. 먼저 스킴(Scheme)은 자원에 어떤 프로토콜을 사용해 접근해야 하는지 나타낸다. http, https, ftp 등이 여기에 해당하는 것이다. 유저는 일부 서비스에서 필요로 하는 사용자의 이름과 비밀번호다. 대부분의 URI에서는 이와같은 기본 정보는 생략된다. 그리고 호스트는 접근하려는 자원이 위치한 서비스의 도메인 이름이나 IP 주소다. 포트는 서버에서 접근하려는 자원을 제공하는 서버의 포트 번호다. 생략하면 기본 번호인 80번이 제공된다. HTTP가 80이기 때문이다. 패스는 서버상의 자원의 경로를 의미한다. 그리고 쿼리는 서버에 전달하려는 추가의 정보다. 보통 우리가 잘 아는 URL 파라미터 형식으로 주어진다. 마지막으로 프레그먼트는 웹 페이지의 문서 내에서 특정 부분을 가리키는 식별자다. URI의 제일 뒷부분에서 해시태그를 붙여 사용한다. 그래서 우리는 URI만 보고 이것이 무엇을 의미하는지 알 수 있어야 하는 것이다.

 

HTTP란 서버와 클라이언트 간의 데이터 전달을 요청과 응답의 형식으로 정의한 프로토콜이다. HTTP의 기본 메커니즘은 클라이언트가 서버에 요청하면 서버가 응답하는 것이다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서버에 HTTP 요청을 하게 되면, 서버에서 이를 해석하여 적절한 응답을 반환한다. 위에 있는 그림이 HTTP 메시지다. 리퀘스트와 리스폰스 모두 각각 다른 구조와 기능을 가지지만, 모두 HTTP와 헤더와 바디로 구성된다는 공통점을 지닌다.

 

HTTP의 각 줄은 CR, LF(＼r ＼n)로 구성된다. 이는 HTTP 메시지에서 첫 줄은 시작줄이고, 나머지는 헤드다. 헤더의 끝도 CRLF 한 줄로 나타낸다. 그리고 각 헤드는 필드와 값으로 구성되며, HTTP 메시지 또는 바디의 속성을 나타낸다. HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤에 오는 모든 줄을 말한다. 클라이언트가 서버에 전송하려는 데이터가 바디에 담긴다. 보통 프록시 같은 도구에서는 CRLF를 다 맞춰주기 때문에 그다지 신경을 쓰지 않게 된다. 다만 직접적인 HTTP 코드를 작성하게 되거나, HTTP 프로토콜 관련 취약점을 파악하기 위해서는 이는 당연히 알아야 하는 개념인 것이다. 

 

HTTP와 HTTPS의 가장 큰 차이는 평문과 암호문의 차이일 것이다. 기밀정보가 유출된다면 이는 당연하게도 큰 문제가 되는데, HTTPS는 TLS를 도입하여 이런 문제를 해결하는 것이다. 공격자가 메시지를 중간에 탈취하더라도 이를 해석하는 것은 불가능하기에 보안이 유지되는 것이다. 

 

DNS는 인터넷에서 도메인 이름을 IP로 변환해주는 서비스다. 사람이 읽을 수 있는 주소를 컴퓨터가 읽을 수 있는 주소로 변환한다고 생각하면 된다. 위에서 주황색 부분이 도메인 주소가 된다. www 같은 것은 서브 도메인이 된다. 

 

DNS의 동작은 다음으로 이해하면 된다. 컴퓨터에서 www.google.com으로 로 들어간다고 가정하자. 현재 내 컴퓨터의 웹 브라우저는 이 서버의 IP를 모른다. 브라우저는 먼저 PC에 설정된 로컬 DNS 서버에서 해당 도메인과 서브 도메인의 IP 주소를 갖고 있는지 물어본다. 이 로컬 DNS 서버는 보통 통신사마다 지정된 곳이 있는데, 사용자가 다른 곳으로 바꿀 수도 있다. 예를 들어, 흔히 8.8.8.8로 설정하기도 하는데, 이 주소는 구글의 DNS 주소의 IP 주소다. 여기 로컬 DNS의 정보에는 이 주소의 정보가 이미 캐싱되어 있을 수도 있고, 없을 수도 있다. 있다면 바로 내 PC로 정보를 반환할 것이고, 만약 없다면, 로컬 DNS는 루트 DNS 서버에다 이 주소에 해당하는 IP 주소를 어디에서 찾을 수 있는지 물어본다. 루트 DNS는 응답으로 .com으로 끝나는 도메인의 서버 IP 주소를 반환한다. 로컬 DNS는 이 주소를 받아서 .com 주소를 찾아간다. .com 담당 서버는 다시 구글 닷컴의 도메인 정보를 가진 구글 닷컴 담당 서버의 IP 주소를 반환한다. 그 주소를 보고 마지막으로 구글 닷컴을 찾아가 보면, 위처럼 구글 닷컴의 여러 서브 도메인별 IP주소가 있는 것을 볼 수 있다. 여기서 www에 해당하는 IP 주소를 알아낸 다음, 브라우저에게 그걸 반환하여 비로소 www.google.com에 접속하게 된다.

 

DNS 레코드 관리에 있어서는 2가지가 있다. A Record는 도메인을 서버의 IP에 직접 연결하는 것이다. 직통 연결인지라 빠르다는 장점을 갖는다. CNAME은 도메인을 별명과 연결하는 것이다. IP가 유동적으로 바뀌는 서버의 경우, 그 바뀌는 IP들에 일정하게 연결되는 다른 도메인, Canonical Name을 쓴다는 것이다. 유동적으로 바뀌는 것을 통신하게 해주지만, 한 가지를 거친다는 단점이 있다.

 

위는 웹에서의 클라이언트와 서버를 도식화한 그림이다. 사실 클라이언트와 서버 통신 구조는 웹에서만 나오는 것이다. 이 구조는 모바일 앱, cs 프로그램, 게임, 자동차 등에서도 확인할 수 있다. 이 구조의 핵심은 클라이언트와 서버가 각자 맡은 역할이 있어 분리되어 있다는 것이다. 그런데 요즘 많이 언급되는 탈중앙화(DeFi)에는 이처럼 중앙집중식의 역할을 하는 서버가 없다. 거기에서는 클라이언트를 제외한 다른 모든 클라이언트가 서버 역할을 하게 되는 개념이다. 다시 돌아와서, 클라이언트와 서버의 프로세스는 간단하다. 먼저 사용자는 컴퓨터를 통해 브라우저를 실행한다. 웹 브라우저에서 웹 페이지를 찾아 클릭하면 그 요청은 회사의 서버로 전달된다. 회사의 서버는 제각각 다르지만, 온프레미스로 직접 서버실에 위치할 수도 있고, IDC나 클라우드 등을 통해 오프 프레미스로 운영하는 경우도 있다. 그럼 서버로 전달한 사용자의 요청은 어떻게 처리할까?

 

먼저 서버의 각 구성요소를 파악해 보자. 클라이언트로부터 요청이 들어오면 그것을 가장 먼저 받아들이는 곳은 웹 서버다. 여기서는 예를 들어 NGiNX 같은 웹 서버 소프트웨어가 사용된다. 엔진엑스의 주요 역할은 들어오는 요청을 적절한 위치로 라우팅하는 것이다. 사실 요청 내용에 따라 처리 방식이 달라지는데, 예를 들어, 클라이언트가 웹 서버에 정적 컨텐츠인 이미지나 CSS, 자바스크립트와 같은 요청을 보내면 엔진엑스는 해당 컨텐츠를 찾아서 바로 클라이언트에게 반환한다. 하지만 동적 컨텐츠에 대한 요청이라면 엔진엑스는 이를 뒷단으로 전달한다. 여기서는 톰캣이나 장고, 자바, 노드JS와 같은 웹 프레임워크가 사용될 수 있다. 톰캣 같은 웹 어플리케이션 서버는 특정 언어로 작성된 웹 어플리케이션을 실행하는 역할을 한다. 여기서 언어는 자바일 수도 있고, 파이썬, 자바스크립트일 수도 있다. 웹 어플리케이션 서버는 그럼 어떻게 요청을 처리할까? 요청을 처리하기 위해 필요한 데이터를 찾는 과정이 시작된다. 이를 위해 어플리케이션은 데이터베이스에 접근해 필요한 데이터를 검색하거나 저장한다. 또 요청이 파일과 관련된 경우에는 파일 서버에 접근하여 필요한 서버를 읽거나 저장하는 것이다. 마지막으로, 모든 처리가 완료되면 웹 애플리케이션 서버는 처리 결과를 다시 엔진엑스에 전달하고, 엔진엑스는 이것을 클라이언트에 반환하는 것이다. 이렇게 요청 처리의 전 과정이 완료된다.

 

그래서 이런 그림이 일반적인 웹의 기본 구조가 되는 것이다.

 

 

클라이언트에서 서버로 보내는 가장 기본적인 요청 중 하나가 바로 GET 요청이다. 사용자가 웹 브라우저의 주소창에 URL에 입력하고 간단한 행위부터 이런 GET 요청이 시작된다. GET 요청을 보낼 때 중요한 점은 요청할 정보를 URL에 포함한다는 것이다. 이거를 쿼리 파라미터라 부르고, URL의 끝부분에 ?를 추가하고 키는값 형태로 데이터를 표시한다. 웹 브라우저는 자동으로 GET 요청을 캐시한다. 동일한 요청을 보낼 때마다 캐시에 저장된 것을 통해 응답함으로써 더욱 효율적인 통신이 되게 하는 것이다. GET 요청은 브라우저의 히스토리에도 기록되는데, 이전에 방문한 페이지를 쉽게 찾아갈 수도 있다. GET 요청은 서버 입장에서 안전한 메소드이기도 하다. GET 요청은 서버의 상태를 변경하지 않기 때문에, 여러번 요청을 보내도 결과가 항상 같다는 특징이 있다. GET 요청은 북마크가 가능하다는 특징도 있는데, 즐겨찾기를 떠올리면 된다. 그래서 이런 특징 때문에 GET 요청은 주로 정보를 조회할 때 사용된다. 그래서 민감한 정보를 전달하는 등의 방식에서는 POST 같은 다른 메서드를 사용하는 것이 좋다. 

 

응답은 주로 3가지 부분으로 구성된다. 상태 코드, 헤더, 응답 본문이 있다. 상태 코드는 응답의 첫 부분에 위치하며, 서버가 클라이언트의 요청을 어떻게 처리했는지를 나타내는 3자리의 숫자코드다. 200, 404 등으로 말이다. 다음으로 나오는 부분인 헤더는 응답에 대한 메타 데이터를 제공한다. 이를 통해 클라이언트를 정보를 올바르게 해석할 수 있다. 헤더는 여러 가지 유형이 있으며, 컨텐츠 유형, 캐싱 정책, 쿠키 등 다양한 추가 정보를 포함할 수 있다. 마지막으로 응답 본문에는 클라이언트가 요청한 실제 데이터가 담겨있다. 본문의 내용은 클라이언트가 요청한 데이터의 종류에 따라 달라진다. 예를 들어, 클라이언트가 웹 페이지를 요청했다면 본문은 HTML 코드를 담고 있을 것이다. 클라이언트가 json으로 요청했으면 본문도 json 형태일 것이고 말이다. 

 

HTTP에서 GET 방식과 함께 널리 사용되는 것이 바로 POST 방식이다. POST 메서드는 클라이언트에서 서버로 데이터를 전송하는 데 주로 사용되며, 주로 서버 상의 리소스를 생성하거나 서버의 상태를 업데이트하는 용도로 사용된다. 이때 전송되는 데이터를 요청 본문에 포함되며, 그 형식은 json, XML 등 다양하다. 이런 POST 메서드는 데이터를 본문 요청에 포함시키기 때문에 GET 메서드와는 다르게 전송할 수 있는 데이터의 크기에 제한이 없다. 하지만 이와는 대조적으로 대조적으로 POST 요청은 히스토리에 기록되지 않고, 웹 브라우저에 자동으로 캐싱되지 않는다. 이런 특성 때문에 사용자가 브라우저의 뒤로가기 버튼을 클릭하거나 페이지를 새로고침할 때 POST 요청은 재전송되지 않는다. 우리가 흔히 회원가입을 하다가 새로고침을 누르거나 뒤로가기를 누르면 경고 메시지가 뜨는 것을 볼 수 있는데, 이게 POST 요청과 관련이 있는 것이다. 또 POST 요청은 GET 요청과는 달리 역동성을 가지지 않는다. 같은 POST 요청을 여러 번 보내면 그만큼 서버의 상태가 바뀔 수 있다. 같은 글 작성 요청을 여러 번 보내면 서버에는 여러 글이 작성되는 것이다. POST 메서드의 이런 특성들 떄문에 새로운 리소스를 생성하거나 기존 리소스를 수정하려고 할 때 주로 쓰이게 된다. 하지만 이런 특성이 자동화된 공격을 통해 서버의 상태를 예기치 않은 것으로 변경시키기도 한다. 즉, POST 메서드는 클라이언트가 서버의 상태를 바꾸려는 의도를 명확히 드러내는 HTTP 메서드인 것이다. 크기가 큰 데이터를 전송하거나, 서버의 상태를 변경하려는 경우에 주로 사용된다. 

 

이에 여러 메서드를 살펴보면 위와 같다. PUT 메서드는 기존의 데이터를 업데이트하는 데 사용된다. 이 경우에도 사용자의 입력이 적절히 검증되지 않았을 때 사용자가 적절한 권한 없이 다른 사용자의 정보를 변경할 수 있다는 문제가 발생할 수 있다. DELETE 메서드는 이름에도 알 수 있듯 리소스 삭제에 쓰인다. 이것도 권한이 없는데 삭제가 가능하다면 문제가 될 것이다. OPTIONS 메서드는 서버가 지원하는 HTTP 메서드의 정보를 반환한다. 이 정보는 서버가 어떤 요청을 지원하는지 알 수 있으며, 특정 서버가 허용하지 않아야 할 요청 메서드의 정보를 찾는 데 도움이 된다. TRACE 메서드는 루프백 테스트를 수행하는데, 요청이 서버에 도달하는 과정에서 어떻게 변경되는지 확인할 수 있다.

 

일반적으로 사용자가 웹 사이트에서 로그인 절차를 거치게 되면, 보유한 아이디와 비밀번호를 입력하여 서버에 로그인 요청을 보내게 된다. 이 요청을 받은 서버는 사용자의 로그인 정보를 확인하고, 요청에 성공했다면 Set Cookie를 포함한 응답을 보낸다. 이 쿠키에는 세션 ID 토큰과 같은 사용자를 식별할 수 있는 정보가 포함되어 있다. 브라우저는 이 셋 쿠키의 지시를 받고 쿠키를 저장한다. 이후 이 쿠키는 사용자가 해당 사이트의 요청을 보낼 때마다 자동으로 포함되어 서버가 사용자를 인식할 수 있게 한다. 이 쿠키 설정에는 특별한 옵션이 있는데, HttpOnly인데 다행히 이건 나도 정말 잘 알고있는 기능이다. XSS 방지에 탁월한 옵션이다. 

 

User Agent는 클라이언트의 정보, 운영체제 정보 등을 서버에 전달한다. 서버는 이것을 보고 사용자의 환경에 맞는 최적화된 응답을 제공할 수 있는 것이다. 가장 쉽게 이해를 한다면, 우리는 통신을 할 때 데스크탑을 통해 하기도 하고, 핸드폰을 통해 수행하기도 한다. 그리고 서버는 이를 구분한다는 것이다. 그래서 각각에 적합한 웹 페이지를 제공하는 것이다. 

 

HTTP 응답코드는 클라이언트의 요청이 서버에서 어떻게 처리되었는지 나타내는 중요 정보다. 응답 코드를 통해 통신 상태를 이해하고, 이를 바탕으로 문제를 진단할 수 있기 때문이다. 200번대는 요청이 성공적으로 처리되었다는 말이고, 300번대 응답코드는 클라이언트의 요청이 더 많은 조치를 필요로 하는 리다이렉션 상태를 나타낸다. 400번대는 클라이언트의 요청에 문제가 있다는 것을 나타낸다. 500번대 응답코드는 서버에서 요청을 처리하는 데 문제가 발생했다는 것을 나타낸다. 만약 인증이 필요하지 않은 상황에서 401 응답코드가 발생한다면 문제가 생겼음을 알 수 있는 것이다.

 

다음은 우리가 각별히 주의깊게 봐야할 3가지 보안요소에 대해 살펴보도록 한다.

인증은 기본적으로 사용자가 본인이 주장하는 사람이 정말 그사람인지 시스템이 확인하는 과정이다. 신원을 증명하는 과정이라고도 한다. 인증은 주로 사용자의 이름과 비밀번호의 조합으로 이뤄지며, 이는 대부분의 사람들이 일상적으로 사용하는 가장 일반적인 인증방식이다. 하지만 이외에도 이메일, 휴대번호 등의 방식이 사용된다. 인증 메커니즘을 통해 시스템은 신뢰할 수 있는 사용자만이 시스템에 접근하도록 보장한다. 인증은 시스템을 부적절한 접근으로부터 보호하는 첫걸음인 것이다. 그렇기에 여기서는 데이터 전송 암호화, 약한 비밀번호 정책, 안전하지 않은 세션 관리 등에 대해 주의해야 한다.

 

세션 관리에 있어 중요한 것으로는 세션, 쿠키가 있다. 이 2가지는 웹 사이트가 사용자의 신원을 확인하고 행동을 추적할 수 있게 해준다. 웹은 기본적으로 상태를 유지하지 않는, Stateless의 성격을 갖고 있다. 웹 서버가 사용자의 페이지를 요청할 때마다 새로운 것으로 간주한다는 것이다. 그렇기에 세션이나 쿠키가 필요해진 것이다. 쿠키는 사용자에 저장되는 텍스트 파일인데, 여기에는 사용자의 행동을 식별하고 추적할 수 있는 정보가 포함되어 있다. 로그인 정보가 저장되는 그런 개념이다. 세션은 서버 측에 저장되는 사용자 정보다. 그래서 서버는 세션을 통해 사용자의 ID를 확인할 수 있다.

 

사용자의 인증 과정을 살펴보도록 한다. 사용자가 웹 서비스에 접속하여 로그인을 시도하는 곳부터 시작한다. 로그인 요청이 들어오면 서버는 데이터베이스에서 사용자의 정보를 조회해 실존하는 사용자인지 확인한다. 이를 확인하면 사용자의 세션을 생성하여 세션 스토리지에 저장한다. 이후 서버는 사용자에게 세션 ID를 발급한다. 이 세션 ID는 사용자 정보를 찾기 위한 고유 식별자다. 사용자는 이제 서버의 특정 기능을 실행하기 위해 요청을 보낼 수 있다. 이때 요청을 보낼 때마다 발급받은 세션 ID를 쿠키 값으로 확인한다. 서버는 쿠키 값을 확인해 세션 ID와 비교하는 것이다. 검증이 완료되면 서버는 사용자 ID를 획득하여 요청을 처리하고 응답을 보낸다. 그런데 만약 쿠키가 탈취되면 어떻게 될까? 이 경우에는 공격자는 탈취한 쿠키값을 이용해 서버에 요청값을 보낼 것이다. 서버는 쿠키를 보낸 주체 자체를 알 수는 없고, 그래서 심각한 문제가 되는 것이다. 이것이 유명한 세션 하이재킹이다.

 

세션 하이재킹은 세션을 탈취해 마치 자기가 원 사용자인 것처럼 행동하는 것이다. 위 그림에서는 MITM이 예시로 쓰였지만, 가장 일반적인 것은 XSS를 통한 세션 하이재킹이다. 그리고 인증에 관한 또다른 공격이 있는데, 바로 Brute Force다. 가능한 모든 조합을 대입해 공격하는 방식이다. 단순하지만 효과적인 방식일 것이다. 왜냐하면 복잡성이 낮은 비밀번호는 이런 공격에 특히 취약한데, 사실 기술의 발달로 8자, 10자의 비밀번호도 이미 복잡성이 아주 낮은 수준이기 때문이다. 

 

그럼 MFA를 적용하면 무조건 안전해질까? 당연히 꼭 그런 것은 아니다. MFA를 우회하는 방법도 있기 때문이다. MFA를 구현하더라도 안전하게 구현하는 방법에 대해 따져보고 적용하여야 할 것이다. 예를 들어 위 그림에서 공격자가 ID/PW를 뚫었다면, 새로운 지문을 등록할 수도 있을 것이다. 그럼 MFA 인증이 무의미해지는 것이다. 이런 것들에 대한 방안을 고려하여 MFA를 적용해야 한다.

 

인증이 사용자가 누구인지 확인하는 과정이라면, 사용자에게 어떤 권한을 줄지, 어떤 범위를 허용할지를 결정하는 과정이 인가다. 물론 여기서도 당연히 최소 권한의 원칙이 적용되어야 할 것이다. 보통 이 경우에 많이 사용하는 방식은 RBAC다.

 

인가에 사용되는 기술로는 JSON 기반의 표준인 JWT가 있는데, 두 개체 사이에서 정보를 안전하게 전송하는 데 사용되는 토큰이다. 사용자의 인증 상태와 권한을 나타내는 데 사용되는 정보를 포함할 수 있다. 그리고 OAuth가 있는데, 사용자가 서비스를 제3의 애플리케이션에 위임할 수 있게 하는 표준이다. 이 두 기술은 각각의 상황에 따라 적용되는 것이다.

 

사용자가 성공적으로 로그인하면 이후의 모든 요청에는 이 JWT 토큰이 포함된다. 특히 SSO에서는 JWT가 많이 사용된다. JWT는 오버헤드가 적고 다양한 도메인에서 사용할 수 있기 때문이다. 그리고 JWT는 토큰을 보낸 이가 누구인지 확인할 수 있고, 컨텐츠가 변조되지 않았음을 보장할 수도 있다. JWT는 크게 헤더-페이로드-서명의 3개로 이뤄지는데, 헤더는 토큰의 유형과 해싱 알고리즘을 명시하고, 페이로드는 클레임이라 불리는 정보들의 집합을 담고 있다. 클레임은 키값쌍의 형태로 이루어져 있다. 서명은 헤더와 페이로드를 검증하는 용도로 쓰인다. 

 

JWT는 별도의 저장소가 필요없다. 사용자의 정보와 이 정보의 무결성을 증명하는 것이 토큰 안에 담겨있기 때문이다. 그래서 JWT는 클라이언트의 상태를 유지할 필요가 없는 Stateless 방식이고, 세션 기반의 인증 방식에서는 서버의 저장소에 저장할 필요가 있기 때문에 Stateful 방식이라 부른다.

 

OAuth는 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로, 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업에서 사용되는데, 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 해준다. 보안성과 편의성을 위한 기술이라 할 수 있다.

 

OAuth 2.0에는 4가지 주요 구성요소로 이뤄진다. 리소스 오너는 사용자를 의미하고, 클라이언트는 리소스 서버에서 제공하는 자원을 사용하는 애플리케이션을 의미하고, 리소스 서버(API 서버)는 자원을 호스팅하며, Authorization 서버는 사용자의 동의를 받아 권한을 부여한다. 

 

OAuth 2.0의 동작과정은 위 그림과 같다. 구글 캘린더를 연동한다고 가정한 동작 과정이다.