호드리

OAuth 에 대해서

3 minute read

OAuth

OAuth(Open Authorization)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트를 접속할 때 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 제3자 클라이언트가 사용자의 접근 권한 위임을 위한 개방형 표준 프로토콜이다.

이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, Apple, 페이스북, 마이크로소프트, 트위터 등이 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.

OAuth1.0

2006년 11월 블레인 쿡은 트위터에 OpenID를 탑재하는 작업을 하고 있었다. 같은 시기, 소셜 북마크 사이트인 Ma.gnolia는, 회원이 OpenID를 사용하여 대시보드 위젯으로 서비스에 접속할 수 있는 인증 방법을 필요로 하고 있었다. 이에 쿡, 크리스 메시나, 래리 하프(Ma.gnolia)는 데이비드 리코던(당시 베리사인)과 만나 OpenID를 활용해 트위터나 Ma.gnolia의 API로 인증을 위임하는 방법을 논의했다. 그 결과, API 접근 위임에 대한 공개 표준이 아직 존재하지 않는다는 결론에 이르렀다.

OAuth의 인터넷 커뮤니티는 2007년 4월에 탄생하여, 소수 인원으로 새로운 공개 프로토콜의 초안을 썼다. OAuth 프로젝트를 알게 된 구글의 드위트 클린턴은 지원을 표명했다. 2007년 7월, 팀은 사양 초안을 완성시켰다. 에런 해머래해브가 가세하여 많은 협력자들의 조정을 실시하여, 보다 정식적인 사양을 작성해나갔다. 2007년 10월 3일, OAuth 코어 1.0의 최종 초안이 발표되었다.

[출처] : 위키피디아

OAuth2.0

탄생 배경

구현이 복잡하고, 웹이 아닌 애플리케이션에서의 지원이 부족하다. HMAC*을 통해 암호화를 하는 복잡한 과정이 있다. 또한 Access Token이 만료되지 않는다는 치명적인 단점이 있다.

– 기능의 단순화, 규모의 확장성 등을 지원한다. – https를 필수로 사용하여 암호화한다. – 2.0은 다양한 인증 방식을 지원한다. – 인증서버와 리소스서버를 분리하였다.

구성

  • Resource Owner: 사용자
  • Client: OAuth2.0을 이용해 로그인 기능을 구현할 주체 서비스이다.
  • Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버이다. 사용자는 이 서버로 ID/Password를 넘겨 인증 코드를 발급받는다. Client는 이 서버로 인증 코드를 넘겨 Access Token을 발급받는다.
  • Resource Server(API Server): 사용자의 개인정보를 가지고 있는 웹 애플리케이션(네이버, 카카오, 페이스북 등)서버이다. Client는 Access Token을 이 서버로 넘겨 개인정보를 응답받는다.

주요 용어

Access Token

리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token입니다.

Refresh Token

Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token입니다. Refresh Token은 일반적으로 Access Token보다 만료 기간이 깁니다.

인증 유형(Authorization Grant Types)

  1. Authorization Code Grant│ 권한 부여 승인 코드 방식

​권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식입니다. 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다. Refresh Token의 사용이 가능한 방식입니다.

​

[그림 1] Authorization Grant: Authorization Code

권한 부여 승인 요청 시 response_type을 code로 지정하여 요청합니다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력합니다. 이 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization Code를 전달합니다. Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환됩니다.

  1. Implicit Grant │ 암묵적 승인 방식

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식입니다.

​암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됩니다. Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험을 줄일 필요가 있습니다.

​Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않습니다. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있습니다.

​

​[그림2] Authorization Grant: Implicit

​권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청합니다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력하게 되며 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달합니다. ​

  1. Resource Owner Password Credentials Grant │ 자원 소유자 자격증명 승인 방식

​간단하게 username, password로 Access Token을 받는 방식입니다.

클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됩니다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다. Refresh Token의 사용도 가능합니다.

​

[그림 3] Authorization Grant: Password

위와 같이 흐름은 간단합니다. 제공하는 API를 통해 username, password을 전달하여 Access Token을 받는 것입니다. 중요한 점은 이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이라는 점입니다.​

  1. Client Credentials Grant │클라이언트 자격증명 승인 방식

​클라이언트의 자격증명만으로 Access Token을 획득하는 방식입니다.

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.

이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없습니다.

​

[그림 4] Authorization Grant: Client Credentials

Leave a comment

You may also enjoy