OAuth 2.0 (Open Authorization 2.0)
-
웹이나 어플리케이션에서 사용자에게 권한을 부여하는 개방형 표준 프로토콜
-
제3의 서비스(우리 서비스)가 사용자 리소스에 접근하기 위한 절차를 정의하고, 사용자에게 제3의 서비스를 사용할 수 있는 권한을 부여한다.
-
Naver, Kakao, Google, Github 등의 소셜 미디어 간편 로그인
-
개발자 관점: 인증, 인가 절차를 구현하지 않아도 사용자 정보를 얻을 수 있다. -
사용자 관점: 개인정보(특히 비밀번호)를 제공하지 않아도 제3의 서비스를 이용할 수 있다.
OAuth 2.0 구성 요소
1) 리소스 소유자(Resource Owner)
- 제3의 서비스를 이용하려는 사용자
- 보호되는 리소스에 대한 액세스 권한을 부여하는 사용자로서 클라이언트를 인증하는 역할을 수행한다.
- 제3의 서비스를 이용하기 위해 네이버 로그인을 통하여 개인정보 제공을 동의한다면 클라이언트를 인증한 것으로 간주한다.
2) 클라이언트(Client)
- OAuth 2.0을 사용해 사용자 리소스에 접근하려는 제3의 서비스(third-party Application) (우리 서비스)
3) 권한 서버(Authorization Server)
- 클라이언트가 리소스 소유자의 권한을 얻을 수 있도록 도와주는 서버
- 사용자 인증, 권한 부여, 토큰 발급을 관리함
4) 리소스 서버(Resource Server)
- 보호되는 리소스를 호스팅하는 서버로서 액세스를 허용하거나 거부한다.
- OAuth 2.0 토큰을 사용하여 클라이언트에게 리소스에 액세스할 권한을 부여하고 실제 데이터를 제공한다.
OAuth 2.0 사용 데이터
1) 액세스 토큰(Access Token)
- 클라이언트가 리소스 서버에 리소스에 접근하기 위한 권한을 부여받는 토큰
- 액세스 토큰은 권한 서버에서 발급한다.
- 사용자 정보를 가져오기 위해서는 액세스 토큰이 필요하다. (가장 중요)
2) 리프레시 토큰(Refresh Token)
- 새로운 액세스 토큰을 발급 받기 위한 토큰
3) 범위(Scope)
- 클라이언트가 리소스에 대한 어떤 작업을 수행할 수 있는지를 정의한 문자열
- 범위는 권한 서버에 의해 정의된다.
- 범위를 아이디, 전화번호로 지정했다면 클라이언트는 이 두 가지 정보에만 접근할 수 있다.
4) 인가 코드(Authorization Code)
- 클라이언트가 액세스 토큰을 얻기 위해 중간 단계로 사용되는 코드
- 클라이언트는 인가 코드를 부여 받은 후 이 코드를 이용해 액세스 코드를 얻을 수 있다.
액세스 토큰을 곧바로 발급하지 않고 인가 코드를 부여하는 이유는?
- 액세스 토큰이 프론트 단에 노출되면 데이터 탈취 위험성이 커지기 때문이다.
- 권한 서버는 클라이언트의 정보가 올바른 경우 Redirect Uri로 인가 코드를 반환한다.
이때, 프론트 단에 인가 코드가 노출되므로 쉽게 탈취가 가능해진다.
만약 인가 코드가 아닌, 액세스 토큰을 반환했다면 사용자 정보를 보호하기 힘들 것이다.
따라서 보안성을 높이기 위해 인가 코드를 이용하여 액세스 토큰을 발급하는 것이다.
프론트 단에서 바로 액세스 토큰을 요청할 수 있는 Implicit OAuth 2.0이 있지만 추천하지 않는다.
OAuth 2.0 권한 부여 과정
- 예시) 내가 네이버 간편 로그인을 이용해서 프로그래머스를 사용하려고 한다.
1) 리소스 소유자: 나
2) 클라이언트: 프로그래머스
3) 권한, 리소스 서버: 네이버
- 인가 코드 받기
1) 나는 프로그래머스 로그인 창에서 네이버 로그인을 시도한다.
2) 프로그래머스가 네이버에 인가 코드를 받기 위하여 요청을 보낸다.
3) 네이버가 나한테 네이버 계정 로그인을 요청한다.
4) 나는 네이버 계정으로 로그인을 하고 프로그래머스가 개인정보를 이용하는 것에 동의한다.
5) 네이버가 프로그래머스에게 인가 코드를 반환해준다.
- 토큰 발급 받기
1) 프로그래머스는 클라이언트 아이디, 시크릿 코드, 인가 코드, Redirect Uri을 사용하여 네이버에 액세스 토큰 발급 받기를 요청한다.
2) 올바른 요청일 경우 네이버가 프로그래머스에게 액세스 토큰을 발급한다.
3) 프로그래머스는 액세스 토큰을 사용하여 '나'의 정보에 접근할 수 있게 된다.
OAuth 1.0 vs OAuth 2.0
1) 구성 요소
- OAuth 1.0: 유저, 서비스 제공자, 소비자
- OAuth 2.0: 리소스 소유자, 클라이언트, 권한 서버, 리소스 서버
2) 토큰 발급
- OAuth 1.0: 토큰을 발급 받기 위해
Request Token이 필요하며 이 토큰을 만들기 위해Signature등의 파라미터가 요구됨 (이때 Signature 생성 과정이 매우 복잡하다고 함) - OAuth 2.0: 토큰을 발급 받기 위해
Authorization Code가 필요하며 이 코드를 만들기 위해Cliend id,Request URL이 파라미터로 요구됨
3) 토큰 만료
- OAuth 1.0: 없음
- OAuth 2.0:
Refresh Token사용
4) 사용자 정보 접근
- OAuth 1.0: 액세스 토큰 사용, 매번 유효성 확인을 필요로 함
- OAuth 2.0: 액세스 토큰 사용
5) 지원 유형
- OAuth 1.0: 웹 어플리케이션
- OAuth 2.0: 다양한 플랫폼
장단점
1) 장점
- 데이터 보안성이 높다.
- 사용자의 편의성을 증진한다.
2) 단점
- 액세스 토큰이 노출되면 데이터 탈취 위험성이 높다.
참고
