직접 구글 로그인 같은 서비스를 만든 이야기 - OAuth 2.0, OpenID Connect
학내 개발팀에서 개발자로 있으면서 여러가지 서비스를 제공해야하는 환경에 놓였어요. 이때, 각 서비스가 굳이 각각의 인증 시스템을 가지고 있을 필요가 없죠. 왜냐하면 서비스를 사용하는 대상은 학부생으로 정해져있지만, 만일 각 서비스가 각각의 인증 시스템을 가지고 있다면 유저가 각 서비스를 처음 사용할 때마다 같은 정보를 입력하는 번거로운 회원가입을 과정을 거쳐야하죠. 사실 회원가입은 문제가 없을 수도 있는데, 정보가 바뀌게 된다면 (주로 휴대폰 번호) 모든 서비스에서 휴대폰 번호를 수정해야하죠. 이때 하나를 놓치기라도 하면 중요한 정보를 받지 못하는 문제가 일어날 수도 있고요.
또한 통합된 인증 서비스를 제공하면 제가 소속된 학내 개발팀이 만드는 서비스 말고도 외부에서 제작하는 서비스가 이 인증 서비스를 가져가서 편하게 연동을 할 수도 있을거에요. 보안을 신경써서 한번 제대로 만들면 다시 인증 시스템을 구현하다가 잘못하여 보안에 취약한 코드를 만들 수 있는 가능성도 막을 수 있어요.
통합 인증 서비스를 만들면서 가장 많이 신경 썼던 것은, 이것을 사용해서 연동하는 개발자가 어떻게 하면 편하게 쓸 수 있을지, 어떻게 하면 보안에 대한 이슈를 최대한 줄일 수 있을지였어요. 이 두가지를 간단하게 만족시킬 수 있는 방법은 이미 표준화 되어있는 기술을 사용하는 것이었어요. 그 기술이 바로 OAuth와 OpenID Connect에요.
보통 OAuth 2.0은 많이 들어봤을 것인데, OpenID Connect는 생소할 수도 있을 것 같아요. OAuth 2.0은 내가 개발하는 서비스에서 다른 서비스(ex: 구글)의 리소스를 가져와서 사용할 수 있는 인가(Authorization)를 지원하는 기술이고, OpenID Connect는 OAuth 2.0을 기반으로하여 유저 정보를 전해주는 인증(Authentication)을 지원하는 기술이에요.
OpenID Connect는 처음 들어보는 표준이었기 때문에 이것을 구현하기 위해 여러 문서(스펙, RFC)를 보면서 오랜 시간 동안 공부를 했어요. 아래 글은 RFC와 스펙 문서를 읽으면서 작동 방식에 대해 정리한 글입니다!
그리고 그 내용을 바탕으로 코드로 옮겼습니다! 사전 지식 글에서도 나오듯이 인증 서비스를 구현하기 위해서 나오는 참여자가 개발하는 서버(클라이언트), 인증 서버, 유저가 사용하는 브라우저(유저 에이전트)로 여러개가 있어서 각자 지금 인증 상태에서는 어떤 작업을 해야하는지를 염두에 두어야 하기에 복잡했던 것 같아요.
새로운 것을 배우고 그것을 그 의도대로 구현해보는 재밌는 경험이었습니다 :)
댓글
로그인 후 댓글을 남길 수 있습니다.
https://medium.com/@sunyi233/id-token%EA%B3%BC-access-token-d285e647ee23