티스토리 뷰
일요일입니다.
이 글은 길었던 OAuth2.0의 이론편 마지막편이 될 예정입니다.
아침에 일어나서 창밖을 보니 어제완 다르게 하늘이 푸르네요.
현재 시간은 오전 11시입니다, 얼른 마무리짓고 오후엔 집 근처 석촌 호수로 벚꽃을 보러 출사를 가야겠습니다.
3. Grant Type
네, 드디어 이론편_#02에서 여러분을 괴롭히고 주구장창 언급했었던 Grant Type 이 나왔습니다.
분명 이번 편에서 상세하게 설명을 해드린다고 했었습니다.
그리고 그만큼 설명할 내용이..많습니다. 하지만 어렵지는 않습니다.
한 번에 휙, 하고 정립만 된다면 말이죠.
0) Intro
본격적인 시작에 앞서서, 간략한 언급을 하고 시작하겠습니다.
Grant Type 은, ‘허가를 받는 유형’ 입니다. 여기서 말하는 ‘허가’에 대해 선정의를 해보겠습니다.
OAuth 2.0 은 토큰을 기반으로 리소스에 접근을 하려고 합니다.
데이터에 대한 CRUD를 하고자 할 때, Client 는 토큰을 HTTP Header 에 담아서 보내고,
OAuth Provider는 해당 토큰이 유효한 지를 판별합니다.
유효하다면, 데이터를 가지고 있는 서버에 접근을 허락하는 것이죠.
그렇다면 여기서 중요한 것은, 누가봐도 ‘토큰’이 됩니다.
그래서 OAuth2.0은 토큰을 기반으로 한 인가 프레임워크라는 말을 1편에서 했었습니다.
자, 그럼 이제 다시, 이 중요하디 중요한 토큰을 발행하는 유형을 논해보겠습니다.
중요하디 중요한 토큰이다보니, 딱! 1가지 유형으로 발행을 해주지는 않습니다.
OAuth 1.0에서는 토큰을 발행해주는 방식이 1가지였습니다만,
2.0부터는 총 5가지의 방식으로 토큰을 발행해 주고 있습니다.
어, 5가지요?
이론편_#2편을 보고 오신 분이라면 제가 Grant Type은 총 4가지라고 했던 걸 기억하실 겁니다.
하지만, 좀 더 집중해서 모든 걸 보신 분이라면 최종적으로 토큰의 발행 방법은 5가지라고 했던 것을 기억하실 겁니다!
그 5가지에 대해 지금부터 설명을 시작합니다.
알아가기 전에 통성명과 간략한 소개부터 해보겠습니다.
1. Authorization Code : 복잡한데 인기도 많고 널리 쓰임
2. Implicit : 간단한데, 간단하긴 한데..어딘가 조금 모자람.
3. Client Credentials : OAuth Provider 가족쯤 됨.
4. Resource Owner Password Credentials : 전권위임.
5. Refresh : 작년에 왔던 각설이가 죽지도 않고 또왔을때.
아직은 봐도 저게 뭔 개소리야..싶으시죠?
이제, 알아보겠습니다.
1) Authorization Code
이 Grant Type을 정의하는 문장은 다음과 같습니다.
‘인가받은 code값을 토대로 토큰을 요청하는 방식’
네, 토큰 마저도 인가를 받아서 발행되는 대상인데 그 토큰을 발행하기 위해서 또 한 번의 인가 받은 code 값을 필요로 합니다. 그래서 해당 방식은 ‘가장 복잡하면서도 가장 많이 쓰이는 방식’이 됩니다.
복잡한 건, 우리 개발자들의 몫이지, 사용자들(고객)의 입장에선 신경을 쓸 필요가 없기 때문입니다. 그리고 복잡한 만큼, 가로채거나 노출의 위험도로부터 좀 더 단단하게 방어적으로 개발이 될 수 있습니다.(물론 우리는 개발자라서 슬픕니다…)
Authorization Code Grant Type의 인가 수순은 아래와 같습니다.
...네, 알아요. 무슨 말을 하고 싶으신 건지.
보자마자 아, 뭐야 이거, 아몰랑 복잡해, 나 안 해, 좀 쉬었다 할까? 싶으시죠?
아니라면 끈기있으신 분이니 좀 더 따라와주시고, 맞다면 쉼호흡 2번만 하시고 찬찬히 다시 보시죠.
사실상 위에서도 언급했다시피…이 방식이 OAuth2.0의 Grant Type 중 제일 복잡한 방식입니다.
(플로우 차트 그리느라 저도 힘들었답니다..ㅠㅠ)
그럼 이제 엉킨 실타래를 풀 듯이, 플로우를 하나하나 풀어서 설명해보겠습니다.
좀 더 쉬운 설명을 위해 모바일 게임 하나와, 네이버 간의 연동을 설명해보겠습니다
(실제로 내부가 이렇게 개발되어 동작되는지는 저는 모릅니다, 하나의 예시일 뿐이에요. 왜냐면 저는 네이버 개발자가 아니라서..)
(아래의 #붙은 번호와, 플로우 차트의 #번호를 비교해서 봐주세요)
#01
먼저, 사용자…여기서는 Resource Owner, 혹은 사용자가 쓰는 Browser로 표현하겠습니다.
사용자는 사용하고자 하는 서비스(Client)인 게임에 접속을 합니다.
그리고 사용자는 해당 게임에서 제공하는 네이버 카페에 글을 쓰기를 원합니다.
(요즘, 모바일 게임들을 보면 게임 공식 네이버 카페에 있는 글을 보여주거나 쓰는 기능들이 들어가 있더라구요, 그 예시입니다.)
게임(Client)는 네이버에게 OAuth2.0을 사용하겠다고 등록을 해놓았고, 그에 걸맞는 client_id와 client_secret을 소유중이기 때문에 네이버가 제공하는 서비스를 가지고 와서 Resource Owner에게 제공할 수 있습니다.
#02
하지만, 네이버는 다양한 서비스를 제공합니다.
블로그에 글을 쓰거나 수정할 수도 있고, 카페에 글을 쓰거나 수정할 수도 있으며 지도API도 이용을 할 수 있죠. 하지만 실제 게임의 사용자는 그저 네이버 카페에 글을 쓰고 읽고 수정하고 삭제하기만을 바랍니다. 그렇기에 블로그나 지도와 같은 수많은 서비스를 모두 사용하고자 할 필요가 없는 것이죠. 그리고 그런 과정에서 사용자는 ‘네이버 카페’에 관련된 기능만을 이 게임(Client)가 사용하게끔 허가(approve)해주겠다는 동의를 해야 합니다.
#03-1
이때, 사전에 이미 동의를 했던 사용자라면, 즉시 code를 발급하는 프로세스를 진행하겠지만
#03-2
동의를 진행하지 않은 사용자라면, 사용자에게 해당 Client가 네이버 카페에 관한 요청을 허가(approve)하는 것에 동의할 것인지를 묻는 페이지를 보여주게 됩니다.
#03-2-1
사용자는 본인의 선택에 따라 동의하지 않을 수도 있고(당연히 동의하지 않으면 해당 서비스를 이용할 수 없습니다) 동의를 한다면, 이 사용자는 해당 Client가 리소스의 동의한 영역에 접근을 허락했다는 것을 Authorization Server측에 저장하게 됩니다.
#04
이제 허가가 떨어졌으니, Authorization Server는 본격적인 토큰 발행을 위해 Authorization Code방식에 따라 Client에게 code를 발행합니다.
해당 code는 쿼리스트링 형식으로 발행이되며, #02 단계에서 Client가 전달했던 redirect_uri의 뒤에 붙어서 전달이 되게 됩니다.
(ex. http://localhost/callback?code=abcdef)
#05
Client는 전달받은 코드를 URI로 부터 발췌해서, 이제야 토큰을 발급받기 위해 필요한 정보들을 코드 값과 함께 body에 채워서 Authorization Server에게 요청하게 됩니다.
#06
이때 토큰 발행을 요청받은 Authorization Server은 2가지를 확인하게 되는데요, 그것은 바로 일전에 본인이 발급했던 code와 Client가 일전에 전달했던 redirect_uri입니다.
code는 본인이 발급한거니 확인하는게 맞다 하더라도, redirect_uri는 갑자기 왜 확인하느냐.
redirect_uri는 사실 OAuth1.0에 있었던 verify의 역할을 여기서 하게 됩니다.
OAuth2.0에선 사라진 verify 정보의 역할은, 해당 Client가 정말 Authorization Server에게 토큰 발행을 요청했던 그 놈이 맞는지를 확인하는 역할이었습니다.
중간에 다른 누군가가 가로채서 정보를 조작해서 토큰 발행을 요청했을 경우를 막고자 하는 역할이었죠.
하지만 OAuth2.0에서는 verity 정보가 사라졌고, 그 역할을 redirect_uri가 대신하게 된 것입니다.
그래서 code와 redirect_uri의 2가지 값의 일치여부를 확인하고 일치한다면 Authorization Server는 이제! 드디어! 토큰을 발행하게 되는 것입니다.
(이때 옵션에 따라 refresh_token이 발행되기도 합니다)
또한 이때 사용되는 code 값은, 1회성임을 유의해주시기 바랍니다.
예를 들어 A라는 Client가 code 값으로 abcdef라는 값을 받아서 해당 값으로 토큰 발행을 요청하려고 했는데, 함께 전달되는 정보(client_id, client_secret, redirect_uri, grant_type)를 잘 못 기입해서 틀릴 경우 abcdef라는 코드 값은 즉시 폐기됩니다.
다시 #02로 돌아가서 진행을 해야 한다는 이야기죠.
#07
Client는 드디어 토큰을 얻었습니다.
그리고 이후 네이버에게 필요한 리소스가 있다면, 앞으로는 헤더에 토큰값을 실어서 요청하게 됩니다.
#08
그리고 그에 따른 요청은 이제 Authorization Server를 지나쳐서 Resource Server가 담당하게 됩니다. Resource Server는 Client가 헤더에 실어서 보낸 토큰 값이 정말 유효한 값인지, 중간에 가로채서 변조되지 않았는지 등을 확인하고 유효한 토큰이라면 리소스의 영역으로 넘겨줘서 Client가 원하는 결과를 가지고 갈 수 있도록 패스시켜줍니다.
#09, #10
그리고 요청이 올바르게 끝나게 되면, Client는 해당 결과를 리턴받고, 사용자 또한 원하던 결과를 확인할 수 있는겁니다.
….설명이 부단히도 길어졌지만, 세세하게 풀어쓴 만큼 이해에 좀 더 도움이 되셨으리라 기대합니다.
마지막으로 한 줄 정리를 해보자면
Authorization Code Grant Type은 Authorization Server에게 토큰을 발행받기 위해서 code값을 요청하고 이 code값을 바탕으로 토큰을 발급받는다! 가 되겠습니다.
2) Implicit
자, 이제부턴 좀 더 간편합니다.
플로우 차트도 심플해지구요. 백문이 불여일견이라, 아래를 봐주세요.
눈썰미가 있으신 분들이라면, 이미 눈치채셨을 겁니다.
Authorization Code Grant Type과 달라진 점이 딱 3가지라는 것을.
하나는 code를 발행하던 flow가 사라졌다는 것이고
하나는 최초의 #02에서 response_type 값이 token으로 바꼈다는 것.
그리고 토큰을 발급해주는 형태가 쿼리스트링이라는 것을요.
네, 그렇습니다.
Implicit Grant Type은 Client의 요청과 동시에 토큰 값을 응답해줍니다.
그래서 response_type이라는 정보를 token이라고 명시해서 보내는 것이죠.
하지만, 그렇기에 Authorization Server가 Client에게 토큰을 리턴해주는 방식이 쿼리스트링으로 전달이 되게 됩니다.
URI에 토큰의 정보고 고스란히…노출이 되는 거죠. 심지어 expires_in이라는 만료시기까지 몽땅요. 사용자의 입장에서는 워낙 빨리 redirect되는 정보고 그 정보를 Client가 받아서 가공한 이후에 돌려주니 토큰이 무엇인지, Expire Time이 언제인지 알기어렵겠지만…해당 정보를 호시탐탐 노리는 분들에게는 좋은 먹잇감으로 노출될 수 밖에 없겠죠.
물론, Authorization Code Grant Type에서도 위와 같은 쿼리 스트링으로 code값이 노출되긴합니다만, code값은 토큰 발행을 위해서 단 한 번 사용할 수 있는 값이라고 말씀을 드렸었습니다. 즉, 리턴 받은 Client가 Authorization Server에게 요청을 때리면 해당 요청의 전달값이 맞든 틀리든 code값은 확인 직후 폐기처리 되는 것이죠.
하지만 토큰의 경우는 다릅니다. 발급된 토큰은 1회성이 아닌 다회성이기 때문에 이후에 OAuth Provider뒤에 있는 리소스에게 Expire Time까지 무한정 접근할 수 있게 되는 것이죠.
그렇다면 안 좋은 거 아냐? 이 방식을 누가 써?? 라고 하실 수 있습니다만 해당 방식은
‘브라우저에서 자바스크립트와 같은 스크립트 언어로 동작하는 클라이언트들을 지원하기 위한 승인 유형입니다. 웹 브라우저의 신뢰도가 높고, 신뢰할 수 없는 사용자나 애플리케이션에 노출될 염려가 적을 때 사용합니다. 모바일 앱 또는 단말기에서 동작하는 웹 애플리케이션에서 주로 사용됩니다.’ 라고 OAuth 2를 이용한 SSO 환경 구축 (1/2)에 작성되어있습니다.
플로우차트의 각 순차별 상세한 설명은 굳이 하지 않겠습니다.
사실상 Authorization Code Grant Type에서 몇가지 단계가 생략되었기 때문입니다.
(혹시 상세 설명이 필요하신 분이 있다면 말씀해주시기 바랍니다.)
한 줄 정리를 하자면 Implicit Grant Type은, 복잡한 거 없이 Client가 토큰 발행을 요청하면 최초의 요청만으로 Authorizaton Server가 토큰을 발행한다, 로만 알아주세요.
3) Client Credentials
네 3번째 토큰 발행 유형입니다.
해당 방법은 사실, 조금 특이합니다.
대부분의 토큰 발행 유형이 Resource Owner가 시발점이 되는데 반해서, 해당 방법은 명칭에서부터 알 수 있듯이 Client가 주권을 쥐고 있습니다. 여타 방법들에서의 허가(approve)에 대한 동의를 Client가 이미 도장 쾅쾅 찍은 상태라고 보시면 됩니다. 즉, 서비스(Client)는 이미 그 자체만으로도 토큰 발행을 요청할 수 있는 주체가 되어있고 토큰을 요청하기만하면 Authorization Server는 토큰을 발행해줍니다.
그래서 해당 방법은 ‘사용자의 승인(approval) 과정이 생략되어있습니다.
그렇기에 어떤 포스팅에서는 해당 Grant Type에서 Resource Owner와 Client를 하나로 보기도 합니다.
주로 사용되는 환경도 관리자용 Desktop App이라던가, 혹은 OAuth Provider와 Client간에 신뢰성이 아주 높은 Application에만 사용이 되게 됩니다. 모바일 앱이라면, 해당 앱을 켜는 것만으로도 사용자가 누군지는 상관없고 리소스를 사용할 수 있게 되는 것이니까요.
그래서 플로우 차트 또한, 아래와 같이 간략화 될 수 있습니다.
네…역대급 심플함이죠?
굳이 설명을 할 필요도 없어보일 정도입니다.
그냥 Client가 토큰 발행을 요청하면, Authorization Server는 토큰을 발행해줍니다.
은행에 대출 받을 때만큼 까다로운 심사같은 프로세스가 필요가 없다는 이야기죠.
왜냐? 해당 Client는 그만큼 OAuth Provider에게 신뢰가 깊은 존재이거든요
(대기업 직원이 은행가면 대출 받기 쉬운 것만큼 신뢰도가 있다는 것이죠)
그래서 Client Credentials Grant Type은 너무너무너무 신뢰가 가는 Client이기 때문에 Authorization Server가 묻지도 따지지도 않고 토큰을 발행해주는 방식입니다.
4) Resource Owner Password Credentials
혹자는 해당 방법을 줄여서 Password Credentials 라고도 합니다.
풀네임은 너무 길기 때문이죠
(몽키 D 루피 같은 건가…)
해당 Grant Type은 사실 바로 위의 Client Credentials와 아주 흡사합니다.
다만, 토큰 발행을 요청할 때 추가되는 정보가 있는데, 그것이 바로 Resource Owner의 Password 입니다. 아, 물론 Resource Owner의 id도 함께 전달됩니다. ID와 Password는 언제나 한 쌍이니까 말이죠.
플로우 차트도 Client Credentials와 비슷합니다.
다만, 이젠 다시 Resource Owner의 영역이 추가가 되었죠.
네, 보시면 아시겠지만, 맨 좌측에 Resource Owner영역이 추가되었습니다.
그리고 Resource Owner는 Client에게 자신의 id와 password를 전달해줍니다.
…말만 들어도 위험해보이죠? 저걸 누가 중간에 채가면 어쩝니까.
채가는 건 그래요 못 채가더라도 Client가 사용자의 id와 password를 알게되는 겁니다.
네이버가 제 아이디랑 비밀번호를 모두 노출한채로 알고 있다고 생각해보세요.
네이버 다니는 친구한테 야, 내 아이디랑 비번 뭐임? 물으면 XX에 OO임. 하고 즉답을 받을 수 있다는 겁니다.
거기에 한 가지 더 위험해보이는 영역이 있습니다.
토큰 발행을 요청하는 방식이, GET 메소드입니다.
그 말인 즉슨, Authorization Server에 토큰 발행을 요청할 때에 필요한 정보들이 URI에 고스란히 노출된다는 의미인데..정보들의 면면을 뜯어보면 크리티컬한 정보들이 있음을 확인하실 수 있습니다. client_secret, password…이 2개만 봐도 헉? 싶은 정보들이죠.
네, 그래서 해당 Grant Type은 Client에 대한 Resource Owner의 100%를 넘어선 1000%쯤의 신뢰도가 바탕이 된다면 사용하시면 되는 방법입니다.
Resource Owner와 Client의, 일급기밀(password & secret)을 죄다 끌어모아서 토큰발행을 요청하는 방식, 그게 Resource Owner Password Grant Type 입니다.
5) Refresh
그리고 대망의 마지막 토큰 발행 방식인, Refresh Grant Type입니다.이것으로 캡틴 플래닛을 드디어…!
Refresh Grant Type은 사실 독립적인 방식은 아닙니다.
혼자 독단으로 토큰을 발행하는 방식은 아니라는 이야기입니다.
여기서 토큰에 대한 재정의를 하고 넘어가야 할 거 같은데요.
사실 제가 지금까지 쭈욱 ‘토큰’이라고 언급했던 개념은 Access Token이었습니다.
제가 토큰이라고 누누히 말해왔던 토큰의 역할은 아래와 같았을 겁니다.
Client가 Authorization Server로 부터 발급받고,
헤더에 담아서 리소스에 대한 CRUD를 요청하고,
요청을 수행하기에 앞서서 Resource Server로부터 검증을 받는 역할.
그리고 이게 토큰의 실질적인 역할이고, 이 역할을 해내는 토큰은 Access Token입니다.
어, 느닷없이 토큰에 대한 개념을 재정의하고 Access Token 이라는 개념을 꺼낸다는 건?
그렇습니다, 또 다른 토큰의 등장을 이야기하고자 함이죠.
(어벤져스에는 캡틴이 둘인데 하나는 아메리카고 하나는 마블이고…뭐 그런 겁니다.)
새롭게 설명할 토큰은 Refresh Token이라고 합니다.
이름을 보면 감을 잡으셨겠지만, Refresh Grant Type을 이끄는 토큰입니다.
OAuth2.0의 장점은 토큰베이스의 인가 방식이지만
OAuth2.0의 단점도 토큰베이스의 인가 방식이라는 것인데요.
다르게 말하면, Access Token만 있으면 리소스에 뭐든 접근을 할 수 있다는 것이고
남의 Access Token을 내가 가지게 되면 남의 리소스에 뭐든 접근을 할 수 있다는 것이죠.
즉, Accee Token이 탈취되면 말짱쾅도루묵 쾅쾅되는 멸망의 길이란 이야기입니다.
그래서 사용하지 않는 Access Token에 대해서는 파기시키는 기능은 기본으로 있어야하며, 이 파기의 주기를 짧게 조절함으로써 행여나 발급된 Access Token이 탈취되더라도 근시간내에 파기되기 때문에 무용지물이 되어야 하는 것이죠.
요근래의 은행사이트를 이용해보신 분이라면 보면 보통 10분내에 로그인을 연장하시겠습니까? 라는 알림이 뜨는 걸 보셨을 겁니다. 인증/인가 받고 접속한 사용자이지만 파기의 주기를 짧게해서 보안성을 높인다, 그거랑 같은 개념이라고 보시면 됩니다.
그리고, 파기 주기를 짧게하는 대신 ‘연장’의 개념이 등장하는데요.
네, 맞습니다. 여기서 연장을 위해 새로운 Access Token이 발급되어야하고, 새로운 Access Token을 발급받는 방식이 Refresh Grant Type이며 이때 사용되는 토큰이 Refresh Token 입니다.
아래 플로우를 보시죠.
Client는 기존에 발행받은 Access Token을 바탕으로 Resource Server에게 리소스를 사용하겠으니 검증을 해달라고 요청했지만, 이미 해당 토큰은 Expire Time에 의해 파기되었기때문에 Invalid access token이라는 에러를 리턴받습니다.
그럼 이제, Client는 사용자(Resource Owner)에게 ‘너 토큰이 만료됐어, 재요청 좀 받아’라고 안내를 해야할까요? 아니면 알아서 사용자로부터 권한을 위임받은 만큼 Access Token을 알아서 재요청해야할까요?
물론, 전자의 방식으로 개발하셔도 상관없습니다.
실제로 그렇게 개발을 하기도 하구요(위에서 언급한 은행을 생각해보세요, 10분에 한 번씩 사용자에게 로그인 연장은 네가 직접 눌러! 라고 하잖아요)
하지만, 여러분이 사용자라면 불편하기 그지없을 프로세스입니다.
10분, 혹은 30분에 한 번씩 내 로그인을 내가 알아서 연장한다?
서비스를 이용하는 고객이 굳이 그런 불편함을 감수해야 할까요.
그래서 Client는 미리 가지고 있던 Refresh Token을 멋지게 꺼내듭니다.
그리고 Authorization Server에게 Access Token의 재발행을 요청합니다.
‘사실 나 아까 인가받은 Client인데 Access Token 좀 다시 발행해줘’라면서 말이죠.
그럼 Authorization Server는 Refresh Token을 체크한 이후에, 유효한 Access Token을 발행해줍니다. 그럼 다시 그 시점부터, Access Token의 Expire Time이 흐르게 되는 것이죠.
이와 같은 방식으로 Access Token의 탈취시 위험도를 줄이면서 사용자에겐 리소스에 대한 접근 편의성을 제공합니다.
그리고 여기서 유의할 점이 있습니다.
Refresh Grant Type은 독단적으로 토큰을 발행할 수 없다고 말씀드렸습니다.
왜냐하면 주재료가 되어 줄 Refresh Token이 있어야지 가능한 것인데,
이 Refresh Token이 발행되는 시점이 최초의 Access Token이 발행되는 시점이기 때문입니다.
즉, 앞서서 설명했던 Grant Type들로 최초의 인가를 받아야지만 사용할 수 있는 Grant Type이라는 이야기죠.
그리고, Authorization Code, Client Credentials Grant Type만이, Refresh Token을 발급받을 수 있다는 사실! 을 꼭 기억해주시기 바랍니다.
네, 차별이에요.
Implicit Grant Type과 Resource Owner Pass Grant Type은 Refresh Token이 발급되지 않습니다. Refresh Token이 발급되지 않으니 당연히, Refresh Grant Type도 사용할 수가 없겠죠.
정리하자면, Refresh Grant Type은 Authorization Code Grant Type혹은 Client Credentials Grant Type으로 최초에 인가를 받았을 경우, 발급되는 Refresh Token으로 Access Token을 재발행 요청하는 Grant Type이다, 가 되겠습니다.
6) Grant Type의 정리
그래서 개발하기에도 복잡하고 플로우도 난잡하지만, code라는 1회성의 정보(마치 OTP처럼)로 Access Token을 발행요청하면서, Access Token을 지속적으로 파기해서 탈취시에 대한 방어를 해내며, Refresh Token을 통해서 Access Token의 재발행요청을 할 수 있는 방법…그래서 Authorization Code Grant Type이 제일 많이 쓰이는 방식이 되는 겁니다
(저는 사실 이건 뭐, 공인만 안 했지 이걸로 하라는 거나 마찬가지 아닌가, 라는 느낌을 받았습니다)
4. 마무으리
네, 드디어 OAuth2.0_이론편의 대단원이 막을 내렸습니다.
어떻게 잘 이해하셨는지는 모르겠습니다만,
이 포스팅을 볼 10년후의 저는 잘 이해하길 바라고 있을 뿐입니다.
그리고 이론편이 끝났으니, 실전편도 있어야겠죠?
다만 언제 실전편을 쓸지는 모르겠습니다…
시간 나는대로 틈틈이 옹기종기 여차저차 한 번 해볼게요..
어느새 3시를 훌쩍 넘겼네요.
그럼 다들 빠빠이 저는 이제 벚꽃 보러 갈겁니다!
'개발 > 백엔드(Back-end)' 카테고리의 다른 글
| [OAuth2_이론 #02] a.k.a 나는 어쩌다 인증을 하게 되었나. (0) | 2019.04.06 |
|---|---|
| [OAuth2_이론 #01] a.k.a 나는 어쩌다 인증을 하게 되었나. (1) | 2019.04.02 |
| [OAuth2_이론 #00] a.k.a 나는 어쩌다 인증을 하게 되었나. (0) | 2019.04.01 |