OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.
-위키백과
최근 어떤 홈페이지나 서비스에 가입하려할 때, 해당 사이트에 회원가입하는 것이 아닌 ~로 로그인/회원가입이라는 것을 많이 봤을 것이다. 어느 사이트를 가나 최소 1~2개 정도는 보인다.
OAuth란 그와 같이 직접 해당 서비스에 회원가입하는 것이 아니라 다른 플랫폼의 저장된 내 인증과 권한을 공통으로 사용하는 것이다.
탄생 배경
기존 비밀번호 인증 방식의 문제
- 신뢰 : 사용자가 애플리케이션에 아이디/비밀번호를 제공하기 꺼림
- 피싱에 둔감 : 여러 애플리케이션에 같은 아이디/비밀번호를 제공한다.
- 접근 범위가 늘어남 : 아이디/비밀번호를 모두 알고 있는 애플리케이션은 동일한 아이디/비밀번호를 쓰는 다른 애플리케이션에도 접근할 수 있음
- 폐기 문제 : 권한을 폐기할 수 있는 유일한 방법이 비밀번호를 바꾸는 것이다.
-> 사용자의 가장 큰 요구는 서드파티 앱에 아이디와 비밀번호를 제공하고 싶지 않다는 것이었다. 해당 앱을 완전히 신뢰할 수 없었기 때문이다.(비교적 큰 기업들에 비해)
작동 흐름
-출처: 페이코
구성
크게 보면 3가지이다.
-
사용자
리소스 소유자. 실제 우리 서비스를 이용하는 유저이다. -
클라이언트 서버
우리가 개발하는 서버이다. 사용자와 로그인하려는 서비스와의 중간 다리 역할을 한다. -
인증 서버
사용자를 인증하고 토큰을 발급해주는 역할을 한다. 구글, 페이스북, 네이버 등 리소스를 가지고 있는 서버이다.
1~2 로그인 요청
사용자가 우리 서비스의 ~로 로그인하기 버튼을 눌러 로그인을 요청한다. 클라이언트 서버는 이때 인증 서버가 제공하는 인증 url에 여러 매개변수를 담아 사용자를 보낸다.
이때 매개변수는 다음과 같다.
- response_type : 반드시 "code"로 값을 설정해야 한다. 인증이 성공한 경우 클라이언트는 authorization code를 받을 수 있다.
- client_id : 애플리케이션을 생성했을 때 받은 client id
- redirect_uri : 애플리케이션을 생성했을 때 등록한 redirect uri
- scope : 클라이언트가 부여받은 리소스 접근 권한. 어디까지 허용할 것인가에 대한 것이다.
3~4 로그인 페이지 제공, id/pw 제공
클라이언트가 빌드한 authorization url로 이동된 사용자는 그 로그인 페이지에서 아이디와 비밀번호를 입력한다.
5~6 authorization code 발급, redirect uri로 리다이렉트
인증이 완료되면, 인증 서버는 제공된 redirect uri로 사용자를 리다이렉션시킬 것이다. 이때, uri에 authorizaion code를 포함하여 보낸다.
이 authorizaion code란 access 토큰을 얻기 위해 사용하는 임시 코드이다. 이 코드는 1~10분 정도로 수명이 매우 짧다.
7~8 authorizaion code와 access token 교환
클라이언트 서버는 인증 서버에 authorizaion code를 전달하고, access token을 받는다. 이후 클라이언트 서버는 발급받은 토큰을 저장한다.
access token은 유출되어선 안된다. 따라서 https 연결을 통해서만 사용할 수 있다.
토큰을 받는 요청에는 다음의 매개변수들이 있다.
- grant_type : 항상 authorization_code로 설정되어야 한다.
- code : 발급받은 authorizaion code.
- redirect_uri : redirect uri
- client_id : 클라이언트 id
- client_secret : 발급받은 시크릿 키
9 로그인 완료
위 과정이 끝나면 클라이언트는 사용자에게 로그인 되었음을 알린다.
10~13 access token으로 리소스 접근
이후 사용자가 인증 서버의 리소스가 필요한 기능을 클라이언트 서버에 요청하면, 클라이언트는 위에서 저장한 access token을 이용해 인증 서버에 리로스를 요청하고 제공받는다.
의문점 - authorizaion code가 필요한 이유?
위의 과정에서 사용자가 처음에 아이디와 비밀번호를 입력한 다음, 인증 코드를 받고, 다시 접근 토큰을 받는다. 여기서 바로 토큰을 받으면 안되는걸까? 왜 인증 코드를 거쳐서 받아야 하는가?
-> 만약 인증 코드를 받는 과정이 생략된다면, 인증 서버가 인증 토큰을 클라이언트에 redirect uri를 통해 전달해야 한다. 이때, url 자체에 데이터를 싣는 방법밖에 없기 때문에, 브라우저에 데이터가 노출된다. 그러나 access token은 노출되어선 안되기 때문에 인증 코드를 받는 과정이 필요한 것이다.
자세히 과정을 보면,
인증 서버 -> url에 인증 코드 담아 프론트엔드로 전달 -> 프론트에서 백으로 인증 코드 전달 -> 백엔드에서 인증 서버로 토큰 요청 -> 백엔드에서 토큰 받고 저장
토큰을 백엔드에서만 다루기 때문에 탈취 위험이 줄어든다.
사실 이외에도 OAuth의 작동 방식은 다양하다. 어떤 작업을 프론트, 백에서 처리할 것인지에 대해 여러 전략이 있을 수 있다. 일단 1~6까지의 과정을 프런트에서 작업하고, authorizaion code를 백에서 전달하고 이후엔 백에서 하는 것을 경험해 보았고, 이 방법이 일반적인 것 같다.
