<개발공부, 개공> OAuth 2.0 개념정리.

 

 

 

8월28일 일요일!

 

오늘은 Oauth의 개념을 알아보고자 한다.

 

요전에 수강했던 부트캠프에서 사용해봤지만 개념부분에서 더 튼튼히 할 필요가 있다고 생각했다.

 

그럼 스타트..!!

 

 

Oauth 2.0란 무엇일까?

 

 

 

 

웹 서핑을 하다 보면 Google과 Facebook 등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있다.

 

클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라,

연동되는 외부 웹 어플리케이션에서 Facebook 및 카카오 등이 제공하는 기능을 간편하게 사용할 수 있다는 장점이 있다.

 

예를 들어, Google로 로그인하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있다.

이 때 사용되는 프로토콜이 바로 OAuth다.

 

 

다음은 Oauth의 정의다.

 

Oauth:

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

 

 

 

역할

 

권한 부여 방식

OAuth 2.0 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류로 구분하여 제공하고 있다.

 

1. Authorization Code Grant │ 권한 부여 승인 코드 방식 ( 실제 내가 썼던 방식! )

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식이다.

 

 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용된다. Refresh Token의 사용이 가능한 방식이다.

 

권한 부여 승인 요청 시 response_type을 code로 지정하여 요청한다.

 

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

 

 

 

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

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

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 된다. 

Access Token이 바로 전달되므로 누출의 위험을 방지하기 위해 만료기간을 짧게 설정하여 전달한다.

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

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

 

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

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

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

위와 같이 흐름은 간단하다.

 

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

 

 

 

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

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

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용된다. 이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없다.

 

7