[Network]OAuth 2.0

OAuth(Open Authorization)는 사용자의 비밀번호 없이도 접근 권한을 받을 수 있는 개방형 표준이다.

 

구체적으로는 사용자가 사용하는 앱(여기서는 클라이언트라 부른다)이 보안을 위해 인증을 다른 업체에게 맡겨버리고

 

서버로부터 접근 권한만 획득하는 방식, 혹은 그 방식에 대한 표준이 OAuth라고 생각하면 된다.

 

두 번이나 반복해서 나왔지만 굳이 강조하자면, OAuth는 인증이 아닌 권한 부여에 대한 표준이다.

 

2007년 버전 1.0이 발표된 이후 2012년 2.0이, 2020년 2.1이 발표되어 현재까지 이르고 있다.

 

더 와닿도록 말하자면 OAuth란 아래와 같은 방식을 말한다.

 

위 스크린샷은 흔히 소셜 로그인이라고 불리는 회원가입 창이다.

 

페이스북, 혹은 구글과 아무런 관련이 없는 핀터레스트가 두 회사에 사용자 인증을 맡기는 것을 볼 수 있다.

 

이는 사용자 편의성 뿐 아니라 웹 앱에서 사용자 정보를 저장하지 않아도 되게 만듦으로써 보안을 향상시키는 효과가 있다.

 

구체적인 절차를 보기 전에 대략적인 진행방식과 자주 쓰이는 단어를 짚고 넘어가자.

 

위에서 먼저 살펴본대로 클라이언트(앱)가 로그인 인증을 서드파티 애플리케이션에 맡기고 

 

권한부여 서버로부터 Access Token을 부여받아 리소스 서버에 접근하는 것을 확인할 수 있다.

 

OAuth에서 쓰이는 용어는 다음과 같다.

 

• Resource Owner - 사용자. 클라이언트 인증 후 권한 획득 자격(Authorization Grant)을 클라이언트에 위임하는 역할.
• Client - 보호된 리소스에 접근하는 애플리케이션, 즉 서버의 클라이언트. 사용자가 사용하는 앱이라 생각하면 된다.
• Third-Party Application - 사용자 인증 과정(Authentication)을 위임받은 기업 및 애플리케이션.
• Authorization Server - 인증 후 클라이언트에게 Access Token의 형태로 권한을 부여하는 서버.
• Authorization Grant - 권한 인증 방식. 크게 네 가지 방식으로 나뉜다.
• Scope - Access Token을 이용해 액세스 할 수 있는 리소스의 범위.
• Resource Server - 리소스(데이터, 서비스)를 제공하는 서버.

또한 OAuth를 사용하는 애플리케이션의 목적은 크게 두 유형으로 나뉘는데,

 

• Third-Party Application의 API를 직접적으로 사용
• 위 이유에 더해 추가적인 인증 서비스 제공

이 그것이다.

 

계속해서 다음 글에선 OAuth의 작동순서와 권한 인증 방식에  대해 조금 더 구체적으로 알아보겠다.