[CS : WEB] OAuth & JWT(JSON Web Token)

1. OAuth

1) OAuth의 흐름

예시 1)

군부대 가족이 김 일병을 면회 온 상황

군부대는 기본적으로 보안을 매우 중요시하고, 특별한 목적 없이는 들어갈 수 없다. 또한 들어간다 하더라도 신분에 따라 머무를 수 있는 시간과 공간이 제약된다.

 

A. 김 일병의 가족이 면회를 온다.

B. 김 일병의 가족은 위병소(출입을 통제하는 곳)에 도착하면, 어떤 목적으로 부대에 방문하려고 하는지, 방문자는 누구인지를 명확하게 밝혀야 한다.

C. 위병소에서는 김 일병에게 가족이 면회 왔다는 소식을 알리고, 실제 가족이 맞는지를 체크한다. 실제 가족이 맞다면 김 일병은 위병소에 가족이 맞다고 전달한다.

D. 위병소에서는 김 일병의 가족에게 면회가 허용된 장소로 안내하고, 그 장소에서만 머무를 수 있는 임시 출입증을 발급한다. 이 임시 출입증은 면회소 외의 장소를 출입할 때는 사용할 수 없고, 18시까지만 머무를 수 있다.

 

 

예시 2)

보일러가 고장 나서, 외부 업체가 수리를 하러 온 상황

 

A. 보일러 수리공이 위병소에 도착해서 자신의 방문 목적과 신원을 명확하게 알린다.

B. 위병소에는 해당 시설 담당자에게 방문하고자 한 보일러 수리공이 맞는지 체크한다. 담당자는 수리하러 온 게 맞으면 맞다고 확인시켜준다.

C. 위병소에서는 보일러 수리공에게 A건물에 출입할 수 있는 임시 출입증을 발급한다. 이 출입증은 A건물에만 내일 18시까지 출입하는 권한을 부여한다.

 

이 두 가지 예시를 통해서 방문자들 모두 방문 목적과 신분에 따라 접근할 수 있는 곳이 달랐다는 것을 주목해야 한다.또한, 부대 내의 구성원이 접근하려는 외부인의 신원을 확인해 주었다는 점도 중요하다. 이 예제를 통해 OAuth의 핵심인 인증과 인가를 확인할 수 있다.

 

OAuth에서 Resource Server는 Resource Owner에게 인증을 받음으로써, 해당 Client가 Resource에 접근할 수 있는지를 확인한다. 그리고 인증된 Client는 자신의 목적에 따라 허용된 정보에만 접근할 수 있다. (또한, 인증된 Client는 자신의 목적에 따라 허용된 정보에만 접근할 수 있다.)

 

즉, OAuth란 “웹, 앱 서비스에서 제한적으로 권한을 요청해 사용할 수 있는 키를 발급해주는 것”이다.

 

 

2) OAuth의 구성

 

A. Resource Owner(DB를 장악하고 있는 OAuth를 사용하는 사람)

B. Authorization Server(OAuth 인증 서버)

C. Resource Server(REST API Server)

D. Client(Resource를 사용하는 직접 사용자)

 

 

3) 실제 적용 사례

※ Facebook의 로그인 방식

 

Facebook은 OAuth 2.0 인증 방식을 사용한다. Client는 본인, 나머지는 Facebook의 서버라고 생각한다.

A. Client가 어떤 사이트를 이용해보려고 하는데 아이디를 Facebook으로 가입할 수 있다는 버튼을 발견한다.

 

B. 버튼을 누르면 Facebook의 로그인 창이 나오고 이를 통해 로그인을 한다.(A, B과정에 해당)

 

C. 로그인을 하고 나면 서버에서 승인을 받아서 B단계가 지났다고 생각하면 된다.

 

D. 로그인 후, 해당 사이트로의 접근을 허용할 것인가에 대한 창이 나타나게 된다.

 

E. 허용을 하게 되면 해당 사이트에서 로그인 목적으로 사용할 수 있는 Access Token을 받게 된다.(C, D 과정에과정에 해당)

 

F. 실제로 보면 Facebook의 Access Token은 다음과 같이 던져준다.

 

{

     "facebook":

     {

          "access_token":"EAAXCfLMud8M*",

          "expiration_date":"2017-01-02T07:43:09.000Z",

          "id":"15037283890"

     }

}

 

여기서부터가 발급받은 Access Token을 이용해서 서비스를 사용하는 과정인 E, F에 해당된다.

 

G. 이제 Access Token의 id를 가지고 access_token으로 서버의 제한된 Resource(DB와 같은)를 expiration_date까지 사용할 수 있다.

 

OAuth 참고자료 출처 : https://gdtbgl93.tistory.com/180 

 

---

 

 

2. JWT

1) JWT란 무엇인가

JSON Web Token의 약자로 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 개방형 표준 모델이다. 이 정보는 디지털 서명이 되어 있으므로 신뢰할 수 있다. JWT는 HMAC알고리즘을 사용하는 비밀키 또는 RSA나 ESDSA를 사용하는 공개 / 개인 키 쌍을 이용하여 서명할 수 있다.

 

서명된 토큰은 그 안에 포함된 클레임의 무결성을 확인할 수 있는 반면, 암호화된 토큰은 다른 당사자들로부터 이러한 클레임을 숨긴다. (클레임 : 사용자 정보나 데이터 속성)

 

2) JSON 웹 토큰이 필요한 경우

A. Authorization

: JWT를 사용하는 가장 일반적인 시나리오다. 사용자가 로그인하면 이후의 각 요청에는 JWT가 포함되어 사용자가 해당 토큰으로 허용된 경로, 서비스 및 리소스에 접근할 수 있다. Single Sign On은 작은 오버헤드와 여러 도메인에서 쉽게 사용할 수 있는 기능으로 인해 오늘날 JWT를 널리 사용하는 기능이다.

 

B. 정보 교환

: JSON 웹 토큰은 당사자간에 정보를 안전하게 전송하는 좋은 방법이다. 예를 들어 공개 / 개인 키 쌍을 사용하여 JWT에 서명할 수 있으므로 발신자가 자신이 말하는 사람인지 확인할 수 있다.(서명 효과) 또한 서명이 헤더와 페이로드를 사용하여 계산되므로 내용이 변조되지 않았는지 확인할 수도 있습니다.

 

3)  JSON 웹 토큰의 구조

압축 형식의 JSON 웹 토큰은 점으로 구분된 세 부분으로 구성된다.

 

A. 헤더

헤더는 일반적으로 토큰 유형과 사용 중인 서명 알고리즘의 두 부분으로 구성된다.

그런 다음에 JSON은 Base64Url로 인코딩 되어의 첫 번째 부분을 형성한다.

 

B. 페이로드

토큰의 두 번째 부분은 클레임을 포함하는 페이로드이다. 클레임은 개체(일반적으로 사용자) 및 추가 데이터에 대한 설명이다.

- 공개 클레임

: JWT를 사용하는 사람들이 원하는 대로 정의할 수 있다. 그러나 충돌을 방지하려면 IANA JSON 웹 토큰 레지스트리에서 정의하거나 충돌 방지 네임 스페이스를 포함하는 URI로 정의해야 한다.

 

- 비공개 클레임

: 사용에 동의하고 등록 또는 공개 클레임이 아닌 당사자간에 정보를 공유하기 위해 생성된 사용자 지정 클레임이다.

 

- 등록된 클레임

: 유용하고 상호 운용 가능한 클레임을 제공하기 위해 필수는 아니지만 권장되는 미리 정의된 클레임 집합이다. 그 중 일부는 iss(발행자), exp(만료 시간), sub(주제), aud(청중) 및 기타이다.

 

C. 서명

서명 부분을 생성하려면 인코딩 된 헤더, 인코딩된 페이로드, 비밀, 헤더에 지정된 알고리즘을 가져와서 서명해야 한다.

 

예를 들어 HMAC SHA256 알고리즘을 사용하는 경우 서명은 다음과 같은 방식으로 생성된다.

서명은 메시지가 변경되지 않았음을 확인하는 데 사용되며, 개인 키로 서명된 토큰의 경우 JWT 발신자가 자신이 말하는 사람인지 확인할 수도 있다.

 

4) JWT 웹 토큰의 작동 플로우

인증 시 사용자가 자격 증명을 사용하여 성공적으로 로그인하면 JSON 웹 토큰이 반환된다. 토큰은 자격 증명이므로 보안 문제를 방지하기 위해 세심한 주의를 기울여야 한다. 일반적으로 필요한 것보다 오래 토큰을 보관해서는 안 된다. 또한 민감한 세션 데이터를 브라우저 스토리지에 저장하는 것은 보안성 부족으로 인해 권장하지 않는다.

1. 애플리케이션 또는 클라이언트가 권한 부여 서버에 권한 부여를 요청

2. 권한이 부여되면 권한 서버는 애플리케이션에 액세스 토큰을 반환.

3. 사용자는 액세스 토큰을 사용하여 보호된 리소스(예 : API)에 접근