Open Authorization (OAuth)
인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방향 표준이다.
API Access Delegation (API 접근 위임)
- Facebook이나 Twitter 같은 인터넷 서비스의 기능을 다른 애플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있다.
- Google로 로그인하면 외부 서비스에서 API를 통해 연동된 계정의 Google Calendar 정보를 가져올 수 있다.
- 외부 애플리케이션은 사용자 인증을 위해 Facebook, Apple, Google 등의 사용자 인증 방식을 사용한다. OAuth를 바탕으로 이 외부 서비스들의 특정 자원에 접근 및 사용할 수 있는 권한을 인가받는다.
1.0 vs 2.0
OAuth 1.0
- 비공식 논의체에 의해 최초로 만들어졌다.
OAuth 2.0
- IETF OAuth 워킹 그룹이 주축이 되어 만들어졌다.
- OAuth 1.0과 호환되지 않는다.
- 인증 절차가 간략하다.
로그인 vs OAuth
- 로그인: 회사 사원이 사원증을 이용하여 건물에 출입
- OAuth: 외부인이 방문증을 수령한 후 회사에 출입
- 방문증을 가진 사람이 출입할 수 있는 곳과 사원증을 가진 사람이 출입할 수 있는 곳은 다르다.
- 직접 서비스에 로그인한 사용자 vs OAuth를 이용해 권한을 인증받은 사용자
OpenID vs OAuth
OpenID
- 주요 목적은 인증(Authentication)
- 로그인
- OpenID Provider에서 사용자의 인증 과정을 처리한다.
- OpenID를 사용하는 서비스(Relying Party)는 OpenID Provider에게 인증을 위임한다.
OAuth
- 주요 목적은 허가(Authorization)
- 서비스의 API를 호출할 수 있는 권한이 있는 사용자인지 확인하는 것
- Facebook의 OAuth를 사용할 경우 Facebook의 사용자인지 인증(Authentication)하는 절차도 있다.
참여자
Resource Server: 제어하고자 하는 자원을 보유하고 있는 서버- Facebook, Google, Twitter 등
Client: Resource Server에 접속해서 정보를 가져오고자 하는 클라이언트(웹 어플리케이션)Resource Owner: 자원의 소유자. Client가 제공하는 서비스를 통해 로그인하는 실제 유저
개발자가 프로그래머스(웹 사이트)에 Github로 로그인한 후, Github의 소스 코드를 가져오려고 한다. 이때 개발자는 Resource Owner, 프로그래머스는 Client, Github는 Resource Server이다.
용어
Client ID: Resource Server에서 발급해주는 ID- Client를 구별할 수 있는 식별자
- 노출해도 무방하다
Client Secret: Resource Server에서 발급해주는 Password- Client ID에 대한 비밀키, 노출해서는 안 된다.
Authorized Redirect Uri: Client 측에서 등록하는 Url- Authorization Code를 전달받을 리다이렉트 주소
- 이 Uri로부터 인증을 요구하는 것이 아니라면 Resource Server는 해당 요청을 무시한다.
