OAuth (Open Authorization) 2.0
HTTP 기반의 인증을 위한 업계 표준 프로토콜
- 사용자의 아이디와 비밀번호 없이 접근 권한을 위임받을 수 있음
로그인 및 개인정보 관리 책임, 사용자의 리소스 조회 등의 기능을 Third-Party Application (카카오,구글 등)에 위임할 수 있음
- 사용자에게 사용자 이름 및 비밀번호를 제공받지 않고도 인증서버(Authorization Server)에서의 정보를 통해서 개인 리소스 공유 가능
- RFC-6759 문서 표준으로 사용됨
OAuth 2.0 장점
- 사용자
- 여러 서비스들을 하나의 계정으로 관리 가능
- ID, Password를 처음 보는 서비스에 넘겨주지 않아도 됨
- 서비스
- 관리하기 민감한 사용자의 ID, Password 정보를 다루지 않아 위험부담 줄어듦
- 서비스 제공자로부터 사용자 정보를 활용 가능
OAuth 2.0 용어
-
HTTP (Hypertext Transfer Protocol)
: 인터넷 상에서 데이터를 주고받는 표준 프로토콜
웹 브라우저와 웹 서버 간에 데이터를 주고받는 데 사용되는 프로토콜
-
프로토콜 (Protocol)
: 디지털 장치 간의 효율적이고 표준화된 통신을 가능하게 하는 규칙의 집합
이러한 규칙은 데이터를 어떻게 송수신할지, 어떤 형식으로 표현할지, 그리고 오류를 어떻게 처리할지 등을 정의
네트워크 통신, 데이터 전송, 파일 공유, 의사소통 등 다양한 분야에서 사용됨
- Authentication 인증
- Authorization 인가
- 자원에 접근할 권한 부여
- 인가가 완료되면 리소스 접근 권한이 담긴 Access Token 클라이언트에게 부여
- Access Token
- 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token
- Refresh Token
- Access Token 만료 시 갱신하기 위한 용도로 사용되는 Token
- 일반적으로 Access Token보다 만료 기간이 길다
- Resource Owner 리소스 소유자, 사용자
- Third-Party Application의 보호된 자원에 접근할 수 있는 자격을 부여해주는 주체
- 클라이언트를 인증(Authorize)하는 역할 수행
- 인증이 완료되면 권한 획득 자격(Authorization Grant)을 Client에게 부여
- Client 개발하려는 서비스
- Third-Party Application의 자원을 사용하기 위해 접근을 요청하는 Service 또는 Application
- Resource Server 데이터를 가진 서버
- 리소스가 존재하고 있는 서버
- 정보를 가지고 있는 API 서버
- 접근 권한이 있는 사용자에게만 접근할 수 있도록 허용
- Authorization Server 인증 담당 서버
- 리소스 서버에 리소스 소유자가 클라이언트를 이용하여 접근할 수 있도록 Access Token을 만들어주는 서버
- 권한 서버, 인증 및 인가를 수행하는 서버
Obtaining Authorization
다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜 4가지
Authorization Code Grant 권한 부여 승인 코드 방식
권한 부여 승인을 위해 자체 생성한 Authorization Code을 전달하는 방식 (기본)
- 클라이언트가 사용자 대신하여 특정 자원에 접근 요청 시 사용
- Refresh Token 사용 가능 방식
- 권한 부여 승인 요청 시 response_type을 code로 지정하여 요청
- 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저에 띄워 출력
- 이 페이지로 사용자가 로그인 시 권한 서버는 권한 부여 승인 코드 요청 시 전달 받은 redirect_url로 Authorization Code 전달
- Authorizaiton Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환


Implicit Grant 암묵적 승인 방식
자격증명을 안전하게 저장하기 힘든 클라이언트(ex. JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식
- 권한 부여 승인 코드 없이 Access Token 발급
- Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험 줄일 필요 있음
- Refresh Token 사용 불가능한 방식
- 권한 서버는 client_secret을 사용해 클라이언트를 인증하지 않음
- 장점 : Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만
- 단점 : Access Token이 URL로 전달됨
- 권한 부여 승인 요청 시 response_type을 token으로 지정하여 요청
- 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저에 띄워 출력
- 로그인 완료 시 권한 서버는 Access Token을 redirect_url로 바로 전달


Resource Owner Password Credentials Grant 자원 소유자 자격증명 승인 방식
간단하게 username, password로 AccessToken을 받는 방식
- 클라이언트가 타사의 외부 프로그램일 경우 적용하면 안됨
- 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식
- Refresh Token 사용 가능
- 제공하는 api를 통해 username, password 전달하여 Access Token 받음
- 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 함


Client Credentials Grant 클라이언트 자격증명 승인 방식
클라이언트의 자격증명 만으로 Access Token을 획득하는 방식
- 가장 간단한 방식
- 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근권한이 설정되어 있는 경우 사용
- 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 함
- Refresh Token 사용 불가

