oAuth 2.0 개념정리

 

oAuth 란

• 구글, 페이스북,트위터와 같은 다양한 플랫폼의 특정 사용자 데이터에 접근하기 위해 제 3자 클라이언트( 우리의 서비스 )가 사용자의 접근 권한을 위임 ( Delegated Authorization ) 받을 수 있는 표준 프로토콜이다.

 

oAuth 2.0 주요 용어

용어	설명
Authentication	인증,접근 자격이 있는지 검증하는 단계를 말한다
Authorization	인가, 자원에 접근할 권한을 부여하는 것, 인가가 완료되면 리소스에 대한 접근 권한이 담긴 Access Token 이 클라이언트에게 부여됩니다.
Access Token	리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료기간이 있는 Token 입니다.
Refresh Token	Access Token이 만료시 이를 갱신하기 위한 용도로 사용하는 Token입니다. Refresh Token은 일반적으로 Access Token보다 만료기간이 길다.

 

 

oAuth 주체

• Resouce Owner
  • 리소스의 소유자 또는 사용자, 보호된 자원에 접근할 수 있는 자격을 부여해 주는 주체.
    oAuth2 프로토콜 흐름에서 클라이언트를 인증 ( Authorize ) 하는 역할을 수행합니다.
  • 인증이 완료되면 권한 획득 자격 ( Authorization Grant ) 을 클라이언트에게 부여합니다. 개념적으로는 리소스  소유자가 자격을 부여하는 것이지만. 권한 서버가 리소스 소유자와 클라이언트 사이에서 중개 역할을 수행하게 됩니다.
• Authorization & Resource Server
  • Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버이다. Resource Server는 구글,페이스북,트위터와 같이 리소스를 가지고 있는 서버를 말한다.

Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지 하나의 서버로 구성할지는 개발자가 선택하기 나름

• Client
  • Resource Server의 자원을 이용하고자 하는 서비스 ( 애플리케이션 ) , 보통 우리가 개발하려는 서비스가 될 것이다

Client는 우리가 구현하는 서비스이므로 Resource Owner와 헷갈리지 말자. Resource Server와 Authorization Server의 입장에서는 우리 서비스가 클라이언트이기 때문.

 

 

 

Obtaining Authorization

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

 

Authorization Code Grant ( 권한 부여 승인 코드 방식 )

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

Authorization Grant: Authorization Code

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

Implicit  Grant ( 암묵적 승인 방식 )

• 자격 증명을 안전하게 저장하기 힘든 클라이언트 ( JavaScript등의 스크립트 언어를 사용한 브라우저 )에게 최적화된 방식.
• 권한 부여 승인 코드 없이 바로 Access Token이 발급됩니다. Access Token이 바로 전달되므로 만료 기간을 짧게 설정하여 누출의 위험을 줄일 필요가 있습니다.
• Refresh Token 사용 불가능. 권한 서버는 client_secert를 사용해 클라이언트 인증을 하지 않음. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율은 높지만 Access Token 이 URL로 전달되는 단점이 있음.

Authorization Grant: Implicit

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

Resource Owner Password Credentials Grant ( 자원 소유자 자격증명 승인 방식 )

• 간단하게 username,password로 Access token을 받는 방식.
• 클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안된다. 자신의 서비스에서 제공하는 애플리케이션일 경우에만 사용되는 인증방식.
• Refresh Token의 사용이 가능

 

제공하는 API를 통해 username,password을 전달하여 Access Token을 받는 방식,

중요한 점은 이 방식은 권한 서버 ,리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용해야하는 방식

Client Credentials Grant ( 클라이언트 자격증명 승인 방식 )

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

 

 

출처 https://blog.naver.com/mds_datasecurity/222182943542