OpenID와 OAuth2.0
요즘 많은 서비스가 소셜 로그인을 지원합니다.
저만 해도 새로운 서비스를 이용할 때, 네이버 또는 카카오 로그인이 있으면 거기에 손이 먼저 가는데요.
번거로운 개인 정보 입력을 생략할 수 있는 소셜 로그인은 사용자 입장에서 참 고맙습니다.
개발자 입장에서도 신규 유저들의 가입 장벽을 낮추고, 인증/인가를 대신 처리해주니 정말 좋죠.
이번 우테코 4기 레벨3 프로젝트에도 거의 모든 팀이 소셜 로그인을 적용했는데요,
제가 속한 줍줍 팀도 Slack 소셜 로그인을 도입했습니다.
그런데 Slack은 OAuth2.0과 OpenID Connect를 이용한 두 가지 로그인 방식을 제공하고 있어서, 둘 중 하나를 선택해야 했습니다.
여러분은 이 둘의 차이를 아시나요?
OAuth2.0와 OpenID Connect
이 둘을 완벽하게 분리해서 얘기하기는 힘듭니다.
OpenID는 OAuth 프로토콜 위에서 동작하기 떄문이죠.
HTTP 통신이 소켓 통신 위에서 동작하는 것과 유사합니다.
아직 OAuth가 생소한 분들은 같은 테코블의 글 OAuth 개념 및 동작 방식 이해하기를 먼저 읽으시는 걸 추천합니다.
OpenID를 관리하는 비영리 재단인 OpenID Foundation에서 직접 정의한 OpenID의 개념은 다음과 같습니다.
OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에서 동작하는 간단한 ID 레이어입니다. 이를 통해 클라이언트 는 인증 서버에서 수행한 인증을 기반으로 최종 사용자의 신원을 확인할 수 있을 뿐만 아니라, 최종 사용자에 대한 기본 프로필 정보를 상호 운용 가능하며 REST와 유사한 방식으로 얻을 수 있습니다. OpenID Connect를 사용하면 웹 기반, 모바일, 자바스크립트 클라이언트 등을 포함한 모든 유형의 클라이언트에서 인증 세션과 최종 사용자에 대한 정보를 요청하고 받을 수 있습니다. 스펙은 확장 가능하므로 필요에 따라 참가자들에게 ID 데이터 암호화, OpenID 제공자 확인, 로그아웃 등을 이용할 수 있습니다.
최종 사용자, 인증 서버등 생소한 용어가 보이네요.
더 쉬운 이해를 위해 OpenID가 동작하는 과정을 예시로 간단히 살펴보겠습니다.
- 최종 사용자(서비스 유저)가 소셜 로그인 버튼을 클릭합니다.
- 웹사이트나 앱 등이 클라이언트로써 OpenID 제공자에
ID token과access token을 요청합니다. - OpenID 제공자는 승인 페이지에서 최종 사용자의 승인을 요청합니다.
- 최종 사용자는 승인 버튼을 눌러 허가합니다.
- OpenID 제공자는 일회용
인증 코드(Authorization code)를 클라이언트에 발급합니다. - 클라이언트는 발급받은
인증 코드와 클라이언트 정보로ID token과access token을 다시 요청합니다. 이 떄 클라이언트 정보는Client ID와Client secret을 의미합니다. - OpenID 제공자는
ID token과access token을 클라이언트에 발급합니다. - 클라이언트는
access token으로 자원 서버에 필요한 자원을 요청합니다.
OAuth절차를 이미 알고 계시다면 차이점이 없다고 생각하실 수 있습니다. 사실 절차상 보이는 차이점은 access token과 함께 하이라이트 된 ID token을 추가 요청/발급한다는 것 밖에 없습니다.
OAuth 위에서 동작한다는 의미가 이제 명확히 보이시나요?
OpenID의 차별점
OpenID Connect는 어떤 차별점을 추가해 사용자에게 어필하고 있을까요?
- 스코프(Scopes):
OpenID Connect의 변경 사항 중 가장 핵심적인 부분입니다.OAuth 2.0애서 제공자가 원하는 대로 요청 범위를 설정할 수 있었습니다. 이는 유연한 사용이 가능했지만, 상호 운용을 거의 완벽히 불가능하게 만들었습니다.OpenID Connect는 이 요청 범위를 openid, 프로필, 이메일, 주소로 표준화했습니다. - 클레임:
요청 범위를 표준화 한 것에 더해,
OpenID Connet는 요청 범위에 속하는 클레임의 종류도 표준화 했습니다. 사용자의 특정 정보와 인증의 세트가 이에 속합니다. 예를 들어given_name과family_name이라는 이름의 클레임을 지정한다면, 외부의 다른 시스템에서 반복과 예측 가능한 형식으로 사용자 정보를 받을 수 있습니다. - ID token
OpenID Connect에서 스코프는 특정한 정보 세트를 요청하는데 사용가능합니다. 이 정보는 클레임 값들로 만들 수 있습니다.ID token의 ID 정보는 상호 운용성에 중점을 둡니다.ID token을 통해 서드 파티 어플리케이션이 여러 웹 어플리케이션에 대해 동일한 인증 정보를 제공받을 수 있습니다.
이ID token은JWT로 생성됩니다. - 사용자 정보 요청 엔드포인트 통일
ID token에 이어,OpenID Connect구현을 통해 표준화된 엔드포인트를 제공합니다. 예를 들어 엔드포인트 중/userinfo를 통해 사용자 메타데이터 정보를 검증할 수 있습니다.OpenID Connect는 엔드포인트 통일로 상호 운용성을 보장하기에 엔터프라이즈급 솔루션에 적합합니다. 상기한 차별점들을 종합해 볼 때, 결국OpenID는OAuth스펙을 통일해 클라이언트간의 상호 운용성을 보장하는 것을 최우선 가치로 둠을 알 수 있습니다.
무엇을 선택할까?
사실 일반 OAuth2.0와 확장된 OpenID Connect 중 무엇을 선택할지, 웹 개발자 입장에서 기술 본연의 특성을 놓고 논의할 일은 적다고 생각합니다.
OAuth 제공사가 각자의 이유로 제공하는 것에 따를 수 밖에 없으니까요.
저희는 서비스 이용자의 특성을 고려해 적절한 제공사를 고르는 것이 더 중요하게 보입니다.
예를 들어 개발자를 위한 서비스라면 GitHub 로그인이 우선시 될 것 같습니다.
아쉽게도 GitHub은 OpenID를 지원하지 않아서, 일반 OAuth를 사용할 수 밖에 없겠네요.
반면, Google 로그인은 OpenID가 적용된 OAuth가 기본 사양이니 OpenID를 쓰지 않을 수가 없습니다.
잘 쓰이는 다른 소셜 로그인도 살펴볼까요?
카카오 로그인은 OAuth를 기본으로, 선택에 따라 OpenID를 활성화 할 수 있습니다!
카카오 로그인을 쓴다면 이제 개발 상황과 기술 특성을 놓고 얘기할 수 있겠네요.
저희가 프로젝트에 적용했던 Slack은 기본 OAuth와 OpenID를 둘 다 지원했지만,
기본 OAuth는 레거시 시스템으로 부르고 OpenID 사용을 권장하고 있었습니다.
하지만 OAuth 특징인 요청 스코프를 명확하게 보여준다는 것이, 사용자에게 더 신뢰를 줄 거라 생각해 OAuth를 채택했습니다.
이상으로 OpenID에 대해 알아봤는데요, 앞으로 소셜 로그인 방식을 두고 선택을 해야할 때 도움이 되었으면 좋겠습니다.