OAuth 2❓❗

: Open Authorization
간단하게 말하자면 소셜 로그인 인증 방식을 구현한 기술을 말한다.

서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜을 직접적으로 관리 하지 않고 인증 서버를 외부의 써드 파티 애플리케이션에 의탁, 분리하는 것을 말한다.

기존의 방식

애플리케이션에서 사용자의 크리덴셜을 저장하는 아키텍처

써드 파티 애플리케이션과의 통신없이 자체 서비스만으로 운영할 경우, 이 방식은 무리없이 처리가 될 것이다. 그러나 외부의 써드 파티 애플리케이션 API를 이용하는 기능이 추가되었다면 사용자는 써드 파티 애플리케이션에도 인증 정보를 보내 인가를 받아야 하고, 해당 서비스를 운영하는 애플리케이션 크리덴셜 저장소에 써드 파티 애플리케이션 인증 정보까지 저장해야 한다.

사용자의 크리덴셜을 두개나 관리해야 하고, 써드 파티 애플리케이션에서 패스워드를 변경하게 된다면 해당 애플리케이션도 추가적으로 업데이트가 이루어져야 한다는 단점을 가진다.

또한, 외부의 애플리케이션에서 사용하는 크리덴셜을 직접적으로 보관하고 있다면 보안상으로 위험하다.

이런 문제점을 보완하기 위해 OAuth2 인증 프로토콜을 사용한다.

OAuth 2의 방식

애플리케이션에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(ex. Google)에서 사용자의 인증을 대신 처리해주고 Resource에 대한 자격 증명용 토큰을 발급한 후, 클라이언트가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식이다.

이 방식을 사용할 경우, 써드 파티 애플리케이션의 사용자 크리텐셜을 별도로 저장할 필요가 없다.

OAuth 2를 사용하는 애플리케이션 유형

1. 써드 파티 애플리케이션에서 제공하는 API의 직접적인 사용

신뢰할 만한 써드 파티 애플리케이션(ex. Google, Github 등)에서 제공하는 API를 직접적으로 사용하는 애플리케이션을 구현하는데 OAtu2를 사용할 수 있다.

2. 추가적인 인증 서비스 제공 용도

특정 서비스를 제공하는 애플리케이션에서 사용자의 크리덴셜을 남기고 싶지 않을 경우 OAuth2 로그인 인증 방법으로 로그인을 한다.

OAuth 2의 동작 방식

OAuth 2 인증 컴포넌트들의 역할

Resource Owner

: 사용하고자 하는 Resource의 소유자.
써드 파티 애플리케이션의 서비스를 이용하는 사용자를 말한다.

Client

: Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션

⭐ Resource를 기준으로 제공 받는 쪽이 Client, 제공 하는 쪽이 Server!
요청 하는 쪽이 Client, 요청에 대한 응답을 하는 쪽이 Server!

Resource Server

: Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버

Authorization Server

: Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버
Resource Owner가 인증에 성공하면 Authorization Server는 Client에게 Access Token 형태로 Resource에 접근할 수 있는 권한을 부여한다.

🧐 OAuth 2 인증 프로토콜에서 사용되는 용어

• Authorization Grant : Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜을 의미, Access Token을 얻기 위한 수단
• Access Token : Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위해 사용하는 자격 증명용 토큰
• Scope : 주어진 Access Token을 사용하여 액세스할 수 있는 Resource의 범위

Authorization Grant 유형

Authorization Grant 은 Access Token을 얻기 위한 수단으로 Authorization Code Grant(권한 부여 승인 코드 방식), Implicit Grant(암묵적 승인 방식), Resource Owner Password Credential Grant(자원 소유자 자격 증명 승인 방식), Client Credentials Grant(클라이언트 자격 증명 승인 방식) 4가지 유형을 가진다.

⭐Authorization Code Grant

권한 부여 승인 코드 방식

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

☝️ Refresh Token 사용 가능!

Implicit Grant

암묵적 승인 방식

별도의 Authorization Code없이 바로 Access Token을 발급하는 방식으로 자격증명을 안전하게 저장하기 힘든 Client(자바스크립트 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식이다.

☝️ Refresh Token 사용 불가능!

Authorization Server는 Client Secret을 통해 클라이언트 인증 과정을 생략한다.

Resource Owner Password Credential Grant

자원 소유자 자격 증명 승인 방식

간단하게 로그인 시 필요한 정보로 Access Token을 발급받는 방식으로 네이버 계정으로 네이버의 다른 서비스 애플리케이션(웹툰, 지도 등)에만 사용되는 인증 방식입니다.

☝️ Refresh Token 사용 가능!

⭐ Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용이 가능

Client Credentials Grant

클라이언트 자격 증명 승인 방식

Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용 가능한 방식으로 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용해야 한다.

☝️ Refresh Token 사용 불가능!