[OAuth2_이론 #02] a.k.a 나는 어쩌다 인증을 하게 되었나.

어느새 벌써 금요일이네요.
내일이면 벌써 주말입니다. 제 집 근처인 석촌호수에서는 내일부터 벚꽃축제를 한다던데 간만에 카메라 챙겨서 출사나 다녀와야겠습니다.

금일 포스팅은 일전에 했던 OAuth2_이론편_#01에 이은 이론편_#02 입니다.

시작전, 간략한 복습

#01 포스팅에서 이야기했던 것들을 간략하게 정리해보겠습니다.

1) OAuth2는 인증이 아니라 인가를 위한 프레임워크다.
2) OAuth2를 활용하기 위해선 4가지의 실물이 필요하다. 
    서비스를 이용할 사람, Resource Owner. 
    서비스를 제공하는, Client.  
    토큰을 발급해주는 인가의 주체자, Authorization Server.
    토큰을 확인해서 리소스에 대한 접근심의를 하는 문지기, Resource Server.

 

위의 2가지가 사실 이전 포스팅의 내용 전부였습니다.
저만큼 짧게 끝나는 정리되는 이야기지만 길게길게 썰을 풀듯이 포스팅을 했었죠.

---

2. 주거니,받거니, 해보자.

이 포스팅을 통해서 OAuth2를 처음 접하는 분이 아니시라면, 

아마 OAuth2에서 쓰이는 Grant Type이라는 용어를 들어보셨을 겁니다. 

‘Grant : 승인하다, 허락하다’ 라는 뜻을 가진 영어단어입니다. 
(인증/인가만으로도 헷갈리는데 허가까지 나왔습니다. 헷갈리시는 분은 적으면서 따라와보시길)

그리고 뒤에 ‘Type : 유형, 종류’이라는 단어가 덫붙여져있죠.
즉, 붙여보자면 Grant Type은 허가해주는 유형을 뜻합니다.
(갑분영, 갑자기 분위기 영어수업....정의를 정확히 내려야 이해와 인지가 명확해지니까요)

누누히 강조합니다만 OAuth2은 인가를 위한 프레임워크입니다. 

그리고 인가는 허가라고 할 수도 있죠.

그럼 여기서 Grant Type...허가의유형이라는 개념이 등장한다는 건, 무엇을 의미하느냐?

바로 OAuth2.0의 Client가 OAuth Provider로부터 허가를 받아가는 방식(토큰을 받아가는 방식!)이 여러개라는 걸 의미합니다. 그래서 Grant Type이 가지는 의미를 좀 더 풀어서 설명하자면 Client가 Authorization Server에게 토큰을 요청할 때에, 이런 방법으로 토큰을 발행해주면 좋겠어, 라고 알려주는 정보입니다.

총, 4가지의 방법...

얘네 4가지 겁나 좋아하네...

 4가지의 방법으로 Client는 Authorization Server에게 토큰 발행을 요청할 수 있습니다.
(사실 토큰을 발행하는 방법은 하나가 더 있긴 합니다만, 지금 당장은 4개로 알아주시고 상세한 내용은 조만간 업로드 될 OAuth2.0_이론편_#3 에서 설명하겠습니다. 다섯 번째가 모여서 드디어 캡틴 플래닛을 소환할 수 있어...!)

1개도 아니고, 2개도 아닌..총 4가지의 방법이 있다면, 당연히 그 4가지 방법에 대해서 가려낼 수 있는 구분자가 있어야 합니다. If~else 분기문에서 조건없이 처리할 순 없잖아요, 그쵸? 

그래서 Client는 Authorization Server에게 토큰 발행을 요청할 때, 각각의 Grant Type에 따라 파라미터(전달값)의 종류를 다르게 하거나, 혹은 같은 종류라하더라도 값을 달리해서 보내게 됩니다.

그리고 Authorization Server는 Client가 보낸 파라미터를 보고, 어떤 형태의 토큰을 요청했는지를 판별해서 후속 프로세스를 진행하게 됩니다.

그래서 우선, Grant Type의 유형을 세세하게 말하기 전에, 대체 어떤 정보들이 Client와 Authorization Server간에 주거니 받거니 하는지 알아보도록 하겠습니다. 

다만, 아래 나열된 정보들은 각각의 Grant Type에 따라 전달이 될 수도 있고, 전달이 되지 않을 수도 있습니다.

어떤 정보가 전달이 되고 되지 않는지는, Grant Type을 이야기할때에 설명하도록 하겠으니 여기서는 이런 값들이 전달 될 수도 있구나 정도로만 알아주세요.

 

1) client_id, client_secret

우리가 네이버나 카카오, 깃헙이나 페북에 접속할 때 id와 password가 필요하듯이 Client도 Authorization Server로부터 인가를 받고 토큰을 받기 위해서는 Client가 가진 고유의 id와 secret(password역할)이 필요합니다.

 

2) redirect_uri

Client가 Authorization Server에게 토큰발행을 요청할때는 종종 브라우저를 아예 redirect해야하는 경우도 발생합니다.

즉, 브라우저의 제어권이 아예 다른 서버로 넘어가 버리는 것이죠.

그리고 그렇게 제어권이 Client로부터 OAuth Provider쪽으로 넘어가버렸다면, 당연히 다시 돌려 받을 수 있어야합니다. 

Resource Owner가 이용하고자 하는 서비스는 Client가 제공하는 서비스니까요.

우리가 G마켓에서 네이버로 로그인을 선택한 후 네이버의 ID와 Password로 로그인했다고해서 네이버 카페나 블로그를 사용하는 건 아니잖아요? G마켓에서 물건 검색하고 최저가보고 장바구니에 담고 구매하고 싶은거지.

그렇기 때문에 우리는 OAuth Provider에게 인증/인가를 요청을 하지만, 다시 제어권을 돌려받을 수 있는 redirect_uri를 같이 넘겨야 합니다. 그리고 OAuth Provider는 우리의 요청을 처리한 이후에, 전달된 특정URL로 redirect되게 되는 것이죠.
(Spring Framework로 백엔드를 구성하신 상태라면, 해당 URL에 매핑 된 Controller의 메소드로 이동되게 되겠죠?)

이와 같이 OAuth2 또한, 토큰을 발행하는 과정에서 Client는 필요시, 인가가 되었을 타이밍에 redirect되어야 할 URI정보를 Authorization Server에게 넘겨주게 됩니다.

 

3) response_type

Client가 Authorization Server에게 ‘토큰발행을 해주세요!’라고 요청을 했을 때, 

Authorization Server가 응답(response)해주는 유형에 대한 정의입니다.

어, 그럼 이 정보에 매핑 된 값이 저 앞에서 말했던 Grant Type을 의미하나요? 라고 생각하실 수 있겠습니다만...아닙니다. 

좋은 건 크게 봐야한다고 배웠습니다

Grant Type에 대한 명시는 ‘grant_type’이라는 정보를 통해 별도로 전달이 됩니다.

그렇다면, 얘는 대체 어디에 쓰이는 건가? 라는 생각이 드실텐데 

위의 설명을 다시 한 번 잘 봐주시면 Client의 요청에 대해서 응답을 해주는 유형을 정의한다고 되어있습니다.

Token의 유형에 대한 정의가 아니라
Client의 요청에 대한 응답의 정의입니다.

헷갈리시죠? 네, 그럴 수 있어요. 저도 그랬거든요.
그래서 일단 몇 가지 사실을 못 박고 가겠습니다.

첫번째, 제가 현재 설명하고 있는 이 정보들은 Grant Type에 따라 Client에서 Authorization Server로 전달이 되기도 하고, 전달이 되지 않기도 한다고 말씀드렸습니다.

두번째, response_type은, 4가지 Grant Type중에서 2가지 방식에만 사용이 됩니다.
해당 방법은 Authorization Code와 Implicit 방식입니다.

우선적인 이해를 위해 관련된 Grant Type에 대해 간략하게만 설명드리겠습니다.
Implicit 방식은 Client가 Authorization Server에게 최초의 요청만으로 토큰을 발행해 줍니다. 그래서 Authorization Server가 응답해주는 방식(response_type)은 ’token’이야, 라고 알려주는 겁니다.

반면에 Authorization Code 방식은 1번의 요청만으로 토큰이 발행되지는 않습니다. Authorization Server에게 토큰 발행을 요청했는데, 나는 ‘code’라는 형태로 응답해줘, 라고 요청합니다. 그래서 이때는 response_type에 ‘code’라는 값을 담아서 요청하게 됩니다.
그리고 이 code라는 정보를 바탕으로 토큰에 대한 발행을 실요청하게 됩니다.
(슬슬 복잡해지는 거 같죠? 아직 Grant Type에 대한 설명이 뒷받침되지 않아서 그렇습니다. OAuth2.0_이론편_#3을 보고 다시 와서 보시면 좀 더 이해가 쉬우실 겁니다)

즉, Client는 Authorization Server에게 나 이번 토큰 발행에 대한 응답요청은 이걸로 받을게, 라고 알려주는 겁니다. 그럼 Authorization Server는 그 응답요청(response_type)에 따라서 결과를 리턴 해주게 됩니다.

 

4) grant_type

네, 위에서 실컷 response_type을 설명하고 여러분의 머릿속에 이해라는 깃발이 심도있게 콱, 하고 박히기도 전에 헷갈리게만드는 grant_type이 등장했습니다.

OAuth2.0 을 처음 접했을 때의 제 모습...물론 외모말구요..

실질적으로 봤을 때, 바로 이 정보를 통해서 Authorization Server는 Client가 어떤 유형으로 토큰 발행을 요청한 것인지를 판별하게 됩니다.
(어, 근데 저기......사...실은 그게 말입니다. 이 정보를 쓰지 않는 Grant Type도 있답니다...? 딱...따~악 한 놈이 그래요. 걔가 누구냐면 위의 response_type 설명때 잠깐 나온 방식인데 ‘Implicit’라는 아이에요. 이 Grant Type은 Authorization Server에 토큰발행을 요청하는 최초의 시도때 response_type 정보에 ‘token’값을 넣어서 전달한다고 했잖아요? 그리고 그 즉시 토큰이 발행되구요. ...네, 그래서 Implicit 방식만은 grant_type이라는 정보를 아예 사용하지 않습니다. 얘만 그래요 애만...)

 

5) scope(optional)

scope의 개념을 쉽게 설명하기 위해 예시를 들어보겠습니다.

1편에서도 빈번하게 들었던 G마켓의 서비스를 이용하고자할 때, ‘네이버로 로그인’을 사용한다는 가정인데요.
(실제 G마켓에는 네이버로 로그인 기능이 없습니다...예시에요)

이때 ‘네이버로 로그인’버튼을 클릭하면 보통은 새창이 뜨고 거기에는 네이버가 제공하는 로그인 화면이 나오게 됩니다. 그리고 ID와 Password를 입력한 후에, 여러분은 로그인에 성공하게 되는데요.

이때, 접하시게 되는 화면은 아마
‘G마켓에서 네이버로부터 아래의 정보를 활용하시는 것에 동의하시겠습니까?’라는 물음이 있는 알림창일겁니다. 

좀 더 상세하게는 ‘Id, 프로필, 사용자의 생일,전화번호 정보를 G마켓의 활용에 동의합니다’와 같은 말이 있고 체크박스를 누르고 동의를 하게 되겠죠.

이때의 ‘동의’는 현 서비스(Client)의 리소스에 대한 접근 동의입니다.

개념적으로 봤을 때, 

Resource Owner로써의 여러분이, 

Resource Server에 있는 리소스에 대해서 

해당 서비스(Client)는 내가 내 리소스에 접근이 가능한 서비스!!

...라고 승인했음을 OAuth Provider에게 알려주는 겁니다.
(참고로 OAuth2 라이브러리 내에서의 해당개념은 Approve, 혹은 Approval과 같은 단어로 쓰입니다...얘도 승인,허가 뭐 이런 뜻인데...-_-...허가가 뭐 이리 많은지)

그리고 이때에 해당 Client가 접근가능하도록 승인된 내 리소스의 범위를 scope라고 합니다.
scope는 사실 OAuth2에서 옵션값으로 되어있습니다. 정해도 되고, 안 해도 되는 값이라는 거죠. 하지만 정하지 않으면? Client는 발급받은 토큰을 바탕으로 Resource Server에 있는 Resource Owner의 모든 리소스에 대해서 접근이 가능해지는 겁니다.

그래서 OAuth2 Provider는 서비스들에 따라 scope를 잘게 조깨놓고 관리를 하는 것이죠. 

네이버를 예로 계속 들어보자면, 어떤 서비스(Client)는 닉네임과 전화번호와 같은 개인정보들에만 접근이 가능하다던가, 혹은 가입한 네이버 카페 목록까지는 접근을 허용한다던가, 하는 식으로요.
(그리고 Resource Owner는 approve 설정을 scope별로 따로따로 설정할 수도 있습니다, 마치 안드로이드 폰에 설치한 하나의 어플이 SMS 기능과 카메라기능과 전화기능에 대한 접근권한을 따로 가져가듯이 말이죠)

Authorization Server로부터 토큰을 발급받은 이후에 Resource Server를 지나서 실제 리소스에 접근을 하려 할 때, Client별로 접근이 가능한 리소스를 구별해놓는 정보.
그게 scope입니다.

 

6) state(optional)

마지막입니다, 오늘도 글이 또..길어지고 있네요.
(오늘은 다 끝낼 수 있으리라 기대했건만...)

마지막이니만큼, 심플하게 정리하겠습니다.

state는 csrf 공격을 막기위한 정보값입니다. 

토큰 발행을 요청하는 Client가, 랜덤한 특정 값을 토큰을 발행해주는 Authorization Server에게 전달합니다. Authorization Server는 해당 값을 잘 가지고 있는 채로 Client에게 응답해주고, 이후 서로는 서로를 구분짓는 표식으로써 state값을 활용하게 됩니다.

---

아..망했네요. 오늘도 글이 길어지고 말았네요.

이 속도면 이론편은 3편에서 마무리 지어야 할 것 같습니다.
(원래 한 편으로 끝내려고 했는데, 어쩌다 여기까지...3편에선 끝낼 수 있겠지...?)

3편에선 토큰을 발행하는 유형을 의미하는 Grant Type에 대해 이야기하도록 하겠습니다.
그럼 빠이