🎈 OAuth

OAuth 2.0

개념

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

즉, 우리 서비스 유저의 타사 플랫폼 정보에 접근하기 위해 타사 플랫폼으로부터 접근 권한을 위임받는 것이다.

필요성

• 다양한 클라이언트 기기들의 인증을 간단히 할 수 있다.
• 직접 ID, Password를 입력받아 우리 서비스의 회원으로 만들 수도 있겠지만, 이런 방식은 데이터 관리와 보안 측면에서 부담스러울 수 있다.

역할

Resource Owner

리소스 소유자이다. 사용자의 정보에 자격을 승인하는 주체이다.

1. 클라이언트를 인증하고
2. 인증이 완료되면 동의를 통해 권한 획득 자격을 클라이언트에게 부여한다.

구글, 페이스북, 네이버 같은 플랫폼에 해당한다.

Client

Resource Owner의 리소스를 사용하고자 접근을 요청하는 어플리케이션이다. Resource Server와 Authorization Server의 입장에서 Client이기 때문에 Client라는 이름을 갖게 되었다.

현재 우리가 개발하고 있는 어플리케이션에 해당한다.

Resource Server

Resource Owner의 정보가 저장되어 있는 서버이다.

Authorization Server

권한 서버이다. 인증과 인가를 수행하는 서버로, 클라이언트의 접근 자격을 확인하고 access token을 발급하여 권한을 부여한다.

인증 방법

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

이미지 출처

클라이언트가 사용자 대신 특정 리소스에 접근을 요청할 때 사용되는 방식이다. OAuth 2.0에서 가장 많이 볼 수 있는 유형이다.

access token을 얻기 위한 인증 코드를 교환하는 단계가 있어 보안에 효과적이다.

1. 클라이언트가 권한 서버에서 제공하는 로그인 페이지를 요청해 브라우저를 띄워 출력한다.
2. 이 페이지를 통해 사용자가 로그인하면 권한 서버는 redirect_url로 인가 코드를 전달한다.
3. 인가 코드로 권한 서버에 access token을 요청한다.

Implicit Grant(암묵적 승인 방식)

이미지 출처

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

이전 방식에서 인증 코드(code) 교환 과정을 뺀 방식으로, 바로 access token을 발급받는다. access token이 바로 전달되므로 노출 위험을 방지하기 위해 만료 기간을 짧게 설정하여 전달된다.

참고

• https://hudi.blog/oauth-2.0/
• https://charming-kyu.tistory.com/36
• https://engineerinsight.tistory.com/163