소셜 로그인 구현을 해보려 한다.
소셜 로그인의 근간 기술은 OAuth와 OpenID라 할 수 있다.
우선 OAuth는 인가(Authorization)이고 OpenID는 인증(Authentication)이라 생각하면 편하다.
기본 소셜 로그인의 흐름(구글 예시) => 큰 문제 존재
- 사용자가 구글 아이디와 패스워드를 제공한다.
- 서비스를 제공하는 웹이 그 계정으로 구글에 로그인
- 구글이 정보 제공
- 서비스 웹은 정보를 가지고 사용자에게 서비스를 제공한다.
이 방법에는 여러 문제들이 존재한다.
- 서비스 웹이 해킹당하면 사용자의 구글 계정 탈취 가능성이 생긴다.
- 서비스 웹이 악의적인 목적으로 사용자의 구글 계정 사용 가능성이 생긴다.
- 구글 계정 정보를 보관하고 있는 서비스 웹도 부담을 가진다.
- 구글도 회원의 정보를 믿을 수 없는 서비스 웹에 맡기는 것이 불안함을 가진다.
=> 이를 해결하기 위해 여러 기업들이 독자적으로 기술을 개발하였으나, 표준화가 되어 있지 않다는 한계가 있었다.
=> 이에 OAuth 표준화 시작
OAuth란?
웹, 모바일, 데스크톱 어플리케이션에서의 간단하고 표준적인 방법으로 보안 인가를 허용하기 위한 개방형 표준 프로토콜이다.
현재는 OAuth 2.0이 최신버전이다.
OAuth를 사용하면 이전의 단점들을 해결할 수 있다.
서비스 웹은 사용자의 구글 아이디와 패스워드 대신 구글이 발급해준 access token을 가지게 되고, access token에는 리소스 접근 범위가 제한되어 있기 때문에 보안적인 요소가 한층 발달되었다!
OAuth에서는 사용자를 Resource Owner, 서비스 웹을 Client, 구글을 Authorization Server/Resource Server라 부른다.
- Resource Owner: 리소스를 소유하여 접근할 권한을 가지고 있고, 클라이언트에게 그 권한을 위임하는 주체
- Client: 리소스 소유자 대신 위임받은 권한으로 리소스를 요청하는 주체
- Authorization Server: 리소스 소유자를 인증하고 클라이언트에 액세스 토큰을 발급하는 서버
- Resource Server: 액세스 토큰을 사용하여 리소스 요청을 수락하고 응답할 수 있는 리소스를 가지고 있는 서버
OAuth 동작 과정
Resource Owner가 Client에 로그인 요청
=> Client가 Authorization Server에 OAuth 인증 요청(Client ID, Redirect URI, Response Type, Scope를 함께 전달)
(scope란 Client에게 허용된 리소스 접근 범위)
=> Authorization Server는 Resource Owner에 로그인 페이지 제공
=> Resource Owner는 해당 페이지에서 로그인
=> Authorization Server는 Authorization Code라는 임시 코드를 Resource Owner에게 발급
=> 그 즉시 Resource Owner는 Authorization Code를 가지고 Redirect URI로 리디렉션
=> Client는 Authorization Code를 통해 Access Token 발급 요청
=> Access Token 발급받음
=> Client는 Access Token 저장, Resource Owner에게 로그인 성공되었다고 알려줌
시간이 흐르고 Resource Owner가 다시 한 번 요청
=> 이 때 Client는 저장된 Access Token을 가지고 Resource Server에 리소스 요청
=> Access Token이 검증되면 리소스 제공
=> Client는 Resource Owner에게 서비스 제공
OpenID
일반적으로 직접 인증 기능을 구축하기 위해서는 사용자로부터 개인정보를 직접 받아야 한다. 하지만 보안사고가 터지면 큰일난다.
또한 요즘같이 많은 서비스를 이용하고 있는 사용자 입장에서도 각각의 서비스들의 아이디, 패스워드를 다 외워야 한다는 부담감이 있다.
- 신뢰할 수 있는 서비스(구글, 페이스북, 트위터 등)에 사용자 인증 절차를 위임한다.
- 사용자는 자신이 신뢰할 수 있는 서비스의 인증 정보 하나로 여러 서비스에서 인증한다.
위와 같은 일을 하기 위해 고안해난 방법이 OpenID이다.
OpenID란?
비영리 기관인 OpenID Foundation에서 추진하는 개방형 표준 및 분산 인증 프로토콜이다.
OpenID를 사용하면 새 비밀번호를 만들 필요 없이 기존 계정을 사용하여 여러 웹사이트에 로그인할 수 있다.
크게 두 가지 주체로 나눌 수 있다.
- IdP(Identity Provider)
- 구글, 카카오와 같이 OpenID 서비스를 제공하는 당사자 - RP(Relying Party)
- 사요자를 인증하기 위해 IdP에 의존하는 주체- 작은 규모의 서비스를 제공하는 우리들의 대부분에 해당한다.
OpenID의 제일 최신 버전이 OpenID Connect이다.
OpenID Connect
OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에 있는 간단한 ID 계층이다.
이를 통해 클라이언트는 REST와 유사한 방식으로 최종 사용자의 신원과 기본적인 프로필 정보를 얻을 수 있다.
OAuth 2.0과 OpenID Connect의 목적 차이
OAuth 2.0은 Access Token을 발급 받고 그 Access Token을 통해서 리소스에 접근하기 위해 사용된다.
반면에 OpenID Connect는 ID Token을 발급 받고 그 ID Token으로부터 사용자 식별 정보를 얻기 위해서 사용된다.
ID Token?
사용자 식별 정보를 담고 있는 토큰, JWT 형식으로 표현
ID Token의 claim에는 기본 데이터 이외에 사용자를 식별할 수 있는 데이터들이 추가적으로 들어있다.
ID Token 발급 방법
Client가 Authorization Server로 OAuth 2.0 요청을 할 때, Scope에 OpenID를 추가하면, ID Token을 받을 수 있다.
굳이 사용하는 이유는??
OAuth 2.0은 사용자에 대한 정보를 명시적으로 제공하지 않는다.
서버의 리소스 접근 권한만 있을 뿐, Access Token만으로는 유저 프로필 정보는 얻을 수 없다.
반면에 OpenID Connect를 통해서 발급 받은 ID Token으로는 서버에 리소스 접근 권한은 획득할 수 없지만 ID Token만으로는 유저 프로필 정보를 획득할 수 있게 된다.
또한 유저 프로필을 가져올 때 OAuth 2.0만을 사용하면 통신이 최소 두 번은 발생한다.
첫 번째 통신은 Access Token을 요청하고 전달 받을 때,
두 번째 통신은 발급 받은 Access Token을 가지고 유저 프로필 정보를 요청하고 전달받을 때이다.
반면 OpenID Connect를 사용하면 한 번의 통신으로도 유저 프로필 정보를 획득할 수 있게 된다.
먼저 Access Token과 ID Token을 한 번에 요청하고, 한 번에 전달한다.
이에 후속적인 요청없이 클라이언트는 방금 전달받은 ID Token을 디코드해서 유저 프로필 정보를 획득할 수 있다.
