OAuth 2.0 동작 방식

OAuth 2.0 인증 컴포넌트

 

Resource Owner

사용하고자 하는 리소스의 주인으로 웹 애플리케이션의 실제 사용자라고 생각하면 편하다.

 

구글 로그인 인증을 통해 사용자가 자신의 구글 계정으로

자신의 리소스를 사용하는 것이기 때문에 Resource Owner라고 부른다.

 

Client

써드 파티 애플리케이션을 사용하지 않는 기존의 웹 애플리케이션에서

클라이언트는 사용자에 해당했지만

OAuth 2.0에서의 클라이언트는 웹 애플리케이션에 해당한다.

 

클라이언트는 서비스를 이용하는 쪽이고 서버는 제공하는 쪽인데

써드 파티 애플리케이션의 서비스를 제공받는 쪽은

웹 애플리케이션에 해당하기 때문이다.

 

Resource Server

클라이언트의 요청을 수락하고 Resource Owner의 Resource를 제공하는 서버로

써드 파티 애플리케이션의 서비스를 제공하는 쪽이 여기에 해당한다고 생각하면 된다.

 

Authorization Server

클라이언트가 Resource Server에 접근할 수 있는 권한을 부여하는 서버로

인증에 성공한 클라이언트에 Resource 접근 권한이 있는 액세스 토큰을 부여한다.

 

인증 처리 흐름

1. Resource Owner의 인증 요청
2. 웹 애플리케이션 서버가 써드 파티 로그인 페이지로 Redirect
3. Authorization Server가 Resource 접근 권한이 있는 액세스 토큰 생성 후 전달
4. 웹 애플리케이션 서버가 액세스 토큰으로 Resource Server에 요청
5. Resource Server가 Resource Owner의 Resource 전달

 

용어

Authorization Grant

클라이언트가 액세스 토큰을 얻기 위한 수단을

Resource Owner의 권한을 표현하는 크리덴셜이다.

 

아래와 같이 4가지 타입이 있다.

1. Authorization Code
   • 자체 생성한 Authorization Code를 전달하여 권한 부여 승인을 하는 방식
   • 가장 많이 쓰이는 방식
   • Refresh Token 사용 가능
   • 권한 부여 승인 요청 시 응답 타입을 code로 지정하여 요청
2. Implicit Grant Type
   • Authorization Code 없이 바로 액세스 토큰을 발급하는 방식
   • 자격증명을 안전하게 저장하기 힘든 클라이언트에서 사용
   • Refresh Token 사용 불가능
   • 권한 부여 승인 요청 시 응답 타입을 token으로 지정하여 요청
3. Client Credentials
   • 클라이언트가 관리하는 리소스에 접근할 때 사용
   • Authorization Server에 클라이언트에 제한된 리소스 접근 권한이 설정된 경우 사용
   • 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용해야 함
   • Refresh Token 사용 불가능
4. Resource Owner Password Credentials
   • 로그인 시 필요한 정보로 액세스 토큰을 발급받는 방식
   • 같은 서비스에서 제공하는 애플리케이션의 경우에만 사용
   • 네이버 계정으로 로그인 하여 네이버의 웹툰, 카페, 블로그 등을 이용하는 경우가 해당
   • 즉 권한 부여 서버, 리소스 서버, 클라이언트가 모두 같은 시스템이여야 함
   • Refresh Token 사용 가능

 

Access Token

클라이언트가 리소스 서버의 보호된 리소스에 액세스 하기 위해 사용하는 자격증명용 토큰

 

Scope

주어진 액세스 토큰을 사용할 수 있는 범위로

액세스할 수 있는 리소스의 범위다.