What the OAuth2.0

생각의 흐름대로 주저리 주저리!!

 

수 많은 블로그에서 저마다의 이해를 바탕으로 저마다의 생각이...온전하지 못한 나를 흔들고 있다.

여긴 오데?? 나는 누구?? 무엇을 하고 있지??...아아어어... 여긴 오데?? 나는 누구??.. 아아아아..

 

내가 내린 결론이 틀릴 수 있다...그냥 껴맞추기로 이해를 해보자.

 

나는 독고다이 솔로다. 해서 혼자 모든 것을 오롯이 해야 한다. 하지만 시간이 없다. 그러하여 인증에 관련된 것들은 위임을 할 것이다. 즉, 나 대신에 더욱 신뢰 있는 친구에게 인증을 부탁한다.(구글, 페이스북, 네이버, 카카오)

 

사실  인증과 관련된 부분을 개발하기엔 녹록한 부분이 아니기에 위임을 하면 편할것이다.

 

근데 위임을 할 친구들이 여럿이다... 각자의 방식으로 !! 그 또한 혼돈이다..해서 위임을 해 주려면 이리이리 샬라샬라 해야 한다고 정의를 해 버렸다. 즉 표준으로 규약(프로토콜:rfc6749)을 해버렸다.

 

그럼 나는 구글 Oauth를 하던, 카카오 Oauth를 하던 구현체는 flow는 동일하다는 것!!

 

Oauth2.0 ? 한마디 : 위임을 위한 프로토콜!

 

내가 만든 Oauth가 표준을 Flow 할 필요는 없지만 표준을 준수 했을때의 힘은 막강하다!!.. 표준!!

 

혼돈이 왔던 용어는 openID connect를 마주하면서 부터다.

 

OIDC는 주 목적은 인증이고 OAuth는 허가란다....엥? 쉬발? 뭐??

 

블로그 1) 외출을 나간 간부는 저녁에 자대에 복귀를 할 때 암구호를 외치고 들어온다.

암구호 자체는 내가 누군인지가 중요한것이 아니고 난 여기를 통과 할 수 있다는 Key이다. : Access Key

: 출입을 위한 AccessKey(암구호)를 국방부(Oauth provider)가 데일리로 발급하는 것이다.

 

블로그 2) 호텔에 가서 체크인을 통해 받은 카드를 가지고 방에 들어간다.

카드는 내가 누군인지가 중요한것이 아니고 내가 방에 들어 갈 수 있다는 Key이다.  : Access Key

: 출입을 위한 AccessKey(방카드)를 호텔(Oauth provider)이 발급하는 것이다.

 

근데 아무나 Access Key 발급을 해주냐????? 

나에 대한 신원을 기본적으로 체크를 해야 한다.

해서 Oauth 프로토콜은 인증에 대한 내용이 있기는 하지만 Access Key를 발급 하기 위한 부가적인 Flow 다.

 

해서  Access Key를 받고 해당 키를 가지고 사용자 정보를 요청을 해야 한다. 그럼  호출이 기본 2번 필요하다.

(1. 토큰에 대한 요청, 2. 정보에 대한 요청)

 

But OIDC는 주 목적이 인증이기 때문에 Access Key가 아닌 애초에 ID Token 발급된다.

 

어렵다. 어려워!! ㅠㅠㅠ

 

참고로 부트2.x 에서 Deprecated 된 Oauth가 깔끔스하게 Boot3.0에서 부활했다.

하지만 우리 회사에 필요한 Oauth는 기본 프로토콜로 사용하기엔 무리가 있어서 그냥 그대로 사용하지 못한다. ㅠㅠ