OAuth(Open Authorization)
사용자가 계정정보를 제공하지 않고 도 다른 애플리케이션, 웹사이트가 사용자의 자원을 안전하게 접근할 수 있도록 허용하는 표준 인증 프로토콜이다.
사전적의미는 이렇고, OAuth에 대해 이해하려면 먼저 Auth의 과정을 간략히 이해할 필요가 있다.
Auth과정
대부분의 웹사이트는 로그인을 통해 인증된 사용자와 비인증 사용자를 구분짓는다.
이때 사용자는 아이디와 비밀번호를 입력하고 확인버튼을 누른 뒤, 인증(로그인)받는다.
위 과정은 어떻게 이루어질까? 사이트마다 구현된 방식이 다르겠지만, 보통 아래와 같은 과정을 거친다.
- Client가 Server로 로그인하기 위한 정보를 전송한다.
2. Server는 Client에게서 받은 데이터로 검증한다.
- (검증이 성공했다는가정)서버는 SessionID or JWT를 생성해 클라이언트에 반환한다.
- SessionID나 JWT를 반환받은 이후부터 클라이언트는 인증된 사용자만 접근 가능한 작업시 반환받은 값을 쿠키/헤더에 담아 작업시 전송한다.
Auth란 결국 서버와 클라이언트간 약속된 규약으로 이루어진다.
OAuth과정
OAuth는 인증의 주체가 해당 서비스가 아닌 다른 서비스(Google, Naver, Github...)다.
출처 : https://cloud.google.com/apigee/docs/api-platform/security/oauth/oauth-introduction?hl=ko
(위 이미지는 구글의 OAuth를 나타낸 것.)
- 사용자가 구글로 로그인 한다. (정보제공 동의 등...)
- 구글 서버에서 인증 코드를 개발자가 사전에 설정한
redirectUri로 보내준다. - 인증코드를구글서버로 보내 토큰을 발급받는다.
- 해당 토큰을 가지고 사용자가 동의한 구글계정 정보를 구글 서버에 요청하여 받아온다.
그림만 보면 간단하다.
그러나 위 그림에선 클라이언트/서버가 구분되어있지 않다.
클라이언트와 서버를 구분지어 OAuth를 진행해보자.
OAuth에서의 클라이언트/서버
OAuth에서 클라이언트와 서버의 역할은 어떻게 나뉠까?
간단하게 생각하면 인증/인가 관련된 로직은 전부 서버에 넣고 클라이언트는 단순히 API요청만 할 수도 있다.
- 사용자가 구글로 로그인 버튼을 누른다. (이때 백엔드 API를 호출하여 백엔드는 redirect 구글 로그인으로 시킴)
- 로그인 성공하면 구글 서버에서 인증코드를 백엔드로 설정한 redirectUri로 받는다.
- 인증코드를 구글 서버로 보내 토큰을 발급받고, 서비스로직을 처리한 뒤 프론트엔드로 redirect한다. (이때 jwt를 쓰던 뭘하던...)
그러나 마찬가지로 해당 로직을 모두 클라이언트에서 진행할 수도 있다.
출처 : https://developers.google.com/identity/protocols/oauth2?hl=ko
서비스와 상황에 따라 적절한 전략을 사용하는 게 중요해보인다.
잘 쓰여진 글한 편 보면 이해가 좀 된다.
