OAuth 2.0 와 OpenID Connect 프로토콜 쉽게 이해하기

 OAuth 2.0 과 OpenID Connect 개념은 이해하기가 어렵습니다. 스피커 Nate가 말하듯이 처음 배우려는 사람들이 구글링해서 이해하려고 하면 힘들고 혼란스러운 경우가 많다고 합니다. Stackoverflow에 설명된 내용을 보고 있는데, 다른 블로그에서 Stackoverflow의 그 답변은 잘못되었다고 말하고 있고, 또 다른 블로그에서는 앞에 둘 다 틀렸고 자신의 방법이 맞다고 하는 경우가 있다고 합니다. 구글링을 통해 발견한 정보들이 잘못된 것도 많다고 합니다. 실제로 저도 똑같은 시행착오를 겪었습니다. 시간이 좀 지나서 유튜브에서 정말 괜찮은 동영상을 발견했고 정말 이해하기 쉽게 잘 설명을 해서 공유하려 합니다. 다만 강의와 자료가 영어로 되어 있어 제가 큰 틀은 한글로 설명해 드리고자 합니다. 

출처(source): 

동영상 링크 ( click)

ppt 링크 ( click )

한글 요약 : 

• delegated authorization 는 내 암호를 알려 주지 않아도 어떤 웹사이트가 내 데이터에 접근할 수 있게 해주는 문제를 해결함. 주위에서도 쉽게 찾을 수 있는 예로, "어떤 앱이 당신의 주소록에 접근하려고 합니다. 허락하시겠습니까?" 와 같은 메세지를 본 적이 있다면 이미 OAuth 프로토콜을 사용한거임. OAuth가 없던 시절엔 사용자의 데이터에 접속하기 위해 접속 정보(이메일주소, 암호)를 직접 물어봤음. 보안상 큰 문제가 됨. OAuth 사용으로 이런 문제를 해결함. 

• High Level 동작 방식 - 사용자가 yelp.com에 접속했는데 yelp.com 사이트에서 구글 contacts(연락처라고 하겠음) 데이터가 필요함. 옛날 같으면 yelp.com에서 구글 로그인 정보를 달라고 했겠지만 그러면 보안상 문제가 되니, 버튼을 누르면 구글 로그인하는 곳으로 감. account.google.com에서 로그인을 하면 내 로그인 정보는 yelp.com이 아니라 구글에 보내는 거임. 로그인 성공하면 팝업이 나오면서 Yelp 란 얘가 니 이런 이런 데이터에 접근하려는데 허락해줄거임? 이라고 물어봄. 허락해주면 redirect 되서 다시 yelp.com 페이지로 가고. 허락을 받았다고 contacts.google.com에 yelp가 얘기함. contacts.google.com은 허락 받은거 확인하고 contacts(연락처) 데이터에 접근하게 해줌. 이게 바로 OAuth 동작 방식임. 

출처 : Nate Barbettini

• 조금 더 깊게 들어가서 본 방식: 사용자가 yelp.com 사이트에 들어가면 yelp.com이 사용자의 구글 연락처가 필요하다고 함. 사용자가 버튼을 누르면, 구글 데이터의  권한을 담당하는 서버로 redirect 함. 인증 요청이 성공적이면 redirect 할 수 있는 URI 정보와 응답받고자 하는 방식을 적은 정보를 함께 구글 authorization 서버로 보냄. 예시에는 가장 일반적인 authorization code를 받기로함.  사용자가 Yelp의 구글 연락처 접근에 허락을 하면 yelp.com/callback로 redirect 하는데 이때 authorization code도 같이 보냄.  Yelp는 다시 authorization 서버인 accounts.google.com으로 가서 authorization code를 주고 액세스토큰(access token)으로 바꿈. 그러면 Yelp는 그 엑세스토큰으로 원하는 데이터를 가진 contacts 서버인 contacts.google.com에서 액세스토큰을 사용해서 정보를 얻음. 만약 Yelp가 토큰에 적히지 않은 권한 밖의 행동을 하면 contacts 서버는 당근 거절함. 예를 들어 contacts 정보만 읽을 수 있는데, 삭제하려고 하면 contacts 서버찡이 막아줌.  

출처 : Nate Barbettini

* scope, 백채널(back channel), 프론트채널(front channel)이란 중요한 개념도 설명하지만 여기선 생략하겠음. 힌트 : 실선과 점선의 차이!  브라우저찡은 프론트채널!   또 생각해 볼 건, 왜 굳이 액세스 토큰을 바로 안 받고, authorization 코드를 받아서 교환하는지도 생각해 볼 것! 

• 마지막으로 OAuth는 원래 delegated authorization(권한)을 위해 만들어졌는데 사람들이 authentication(인증)을 하는데도 막 씀. OAuth는 인증을 하기 위해 만들어진게 아님. Nate도 OAuth를 인증하는데 쓰지 말라고 함. 결국 OpenID Connect는 인증(authentication)을 위해 만들어진 프로토콜임. OAuth를 잘이해했다면 OpenID Connect는 개껌임! 잘근잘근 씹어먹을 수 있음.

출처 : Nate Barbettini

 한 시간짜리 세션 짧게 요약해봄. 

- The End -