OAuth(Open Authorization)
OAuth
OAuth(Open Authorization)이란 인터넷 사용자들이 비밀번호를 제공하지 않고, 다른 웹사이트상의 자신들의 정보에 대해 웹사이트 혹은 애플리케이션 등의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준을 말한다.
사용자의 아이디와 비밀번호 없이 접근 권한을 위임받는다는 것은 로그인 및 개인정보의 관리 책임을 Third-party apllication(google, kakao, naver 등)에 위임할 수 있다는 것으로, 개인정보 관리 책임을 위임하는 것뿐만 아니라 부여받은 접근 권한을 통해 이들이 가지고 있는 사용자의 리소스를 조회하는 등의 기능을 수행할 수도 있다. 간단히 설명하자면, 제3자 웹사이트에 저장된 사용자의 정보에 대해 접근할 수 있는 권한을 위임받는 것이다.
2010년 최초 OAuth 1.0 공식 표준안이 발표되고, OAuth 1.0의 세션 고정 공격을 보완한 OAuth 1.0a를 거쳐 현재 OAuth의 구조적인 문제점을 해결하고 핵심 요소만을 사용한 유사 프로토콜 WRAP(Web Resource Access Protocol)을 기반으로 발표된 OAuth 2.0이 주로 사용되고 있다.
OAuth 2.0은 다양한 클라이언트 환경에 적합한 인증(Authentication) 및 인가(Authorization)의 부여 방법을 제공하고, 그 결과 클라이언트에 접근 토큰(Access token)을 발급하는 프레임워크라고 할 수 있다.
OAuth 1.0 vs OAuth 2.0
| 비교 | OAuth1.0 | OAuth2.0 |
|---|---|---|
| 역할(역할 명칭 변경 및 세분화) | 이용자(User) 소비자(Consumer) 서비스 제공자(Service Provider) | 자원소유자(Resource Owner) 클라이언트(Client) 자원 서버(Resource Server) 권한 서버(Authorization Server) |
| 토큰 | 요청 토큰(Request Token) 접근 토큰(Access Token) | 접근 토큰(Access Token) 재발급 토큰(Refresh Token) |
| API 호출 인증 및 보안 | 서명 | HTTPS(SSL/TLS) 기본 서명 : 자원 서버가 별도 서명을 요구하는 경우 |
| 유효기간 | 접근 토큰의 유효기간 없음 | 접근 토큰 유효기간 부여 만료 시 재발급 토큰 이용 |
| 클라이언트 | 웹 서비스 | 웹, 앱 등 |
OAuth 2.0의 구성 요소
- Client
- Third-party application의 자원을 사용하기 위해 접근을 요청하는 서비스 혹은 애플리케이션
- 개발하려는 서비스
- Resource Owner
- 리소스의 소유자 혹은 사용자로, 클라이언트의 서비스를 통해 로그인하는 실제 유저
- Third-party application에서 보호하는 자원에 접근할 수 있는 자격을 부여하는 주체
- 클라이언트를 인증(Authorize)하는 역할을 수행하며, 인증 완료 시 권한 획득 자격(Authorization grant)을 부여함
- 개념적으로는 리소스의 소유자가 자격을 부여하지만, 일반적으로는 Authorization server가 resource owner와 client 사이에서 중개 역할을 수행함
- Authorizatio Server
- 권한 서버로서 인증/인가를 수행
- 클라이언트의 접근 자격을 확인하고 Access token을 발급하여 권한을 부여
- Resource Server
- 사용자의 보호된 자원(리소스)을 가지고 있는 서버
- google, naver, kakao 등
주요 용어
| 구분 | 설명 |
|---|---|
| Authentication(인증) | 자원에 접근할 자격이 있는지 검증하는 단계 |
| Authorization(인가) | 자원에 접글할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token을 제공하는 단계 |
| Access Token | 리소스 서버에서 리소스 소유자의 정보를 획득할 때 사용되는 토큰 만료 기간이 존재함 |
| Refresh Token | Access Token 만료 시 이를 재발급받기 위한 용도로 사용하는 Token |
인증 절차의 종류
권한 부여 승인 코드 방식(Authorization Code Grant)
- 권한 부여 승인을 위해 자체 생성한 Authorization code를 전달하는 방식으로, 가장 많이 쓰이고 기본이 되는 방식
- 간편 로그인 기능에서 사용되는 방식으로서, 클라이언트가 사용자를 대신해 특정 자원에 접근을 요청할 때 사용되는 방식
- Refresh token의 사용이 가능
전체적인 흐름을 정리하면 다음과 같다.
- 권한 부여 승인 요청 시 response_type을 code로 지정하여 요청
- 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저에 출력
- 사용자가 로그인을 하면 권한 서버가 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization code를 전달
- Authorization code는 권한 서버에서 제공하는 API를 통해 Access token으로 교환됨
암묵적 승인 방식(Implicit Grant)
- 자격증명을 안전하게 저장하기 힘든 클라이언트(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)
- 사용자 이름과 패스워드로 Access token을 받는 방식
- 클라이언트가 타사의 외부 프로그램이 아닌 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용
- Refresh token 사용 가능
이 방식은 제공되는 API를 통해 사용자의 이름과 패스워드를 바로 전달하여 Access token을 받는 방식이며, 구조만 보아도 알 수 있듯 권한 서버와 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때만 사용할 수 있는 방식이다.
클라이언트 자격 증명 방식(Client Credentials Grant)
- 클라이언트의 자격 증명만으로 Access token을 획득하는 방식
- OAuth 2.0의 권한 부여 방식 중 가장 간단한 방식
- 클라이언트 자신이 관리하는 리소스에 접근하거나, 혹은 권한 서버에 해당 클라이언트만을 위한 제한된 리소스 접근 권한이 설정된 경우 사용
- 자격 증명을 안전하게 보관할 수 있는 클라이언트에만 사용되어야 하며 Refresh token은 사용 불가함
참고 자료
