OAuth 2란 무엇일까요?

전통적으로 특정 애플리케이션의 서비스를 이용하는 사용자에 대한 인증 처리는 해당 서비스를 직접적으로 제공하는 애플리케이션에서 담당해 왔습니다.

인증 서버를 별도로 분리해서 인증을 처리하든 하나의 서버에서 사용자의 인증도 처리하고 그와 동시에 애플리케이션의 서비스도 함께 제공하든 어쨌든 서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜(Credential)을 직접적으로 관리하는 것이 일반적입니다.

OAuth 2란 무엇일까요?

전통적으로 특정 애플리케이션의 서비스를 이용하는 사용자에 대한 인증 처리는 해당 서비스를 직접적으로 제공하는 애플리케이션에서 담당해 왔습니다.

인증 서버를 별도로 분리해서 인증을 처리하든 하나의 서버에서 사용자의 인증도 처리하고 그와 동시에 애플리케이션의 서비스도 함께 제공하든 어쨌든 서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜(Credential)을 직접적으로 관리하는 것이 일반적입니다.

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

즉, 앞에서 언급한 일정 관리 서비스 애플리케이션을 예로 들어 OAuth 2 인증 프로토콜에 대한 개념을 간단히 정리하자면, 아래의 [그림 4-31]과 같이 일정 관리 서비스 애플리케이션을 사용하는 사용자의 Google 전용 크리덴셜(Credential)이 일정 관리 서비스 애플리케이션에 직접적으로 제공되지 않아도 됩니다.

로그인 자체는 구글 로그인 인증을 이용하고, 구글 로그인에 성공하면 Access Token을 전달받아서 Google Calendar API를 사용하기 위해 Access Token을 이용합니다.

[그림 4-31] 써드 파티 애플리케이션의 크리덴셜을 저장하지 않는 아키텍처

일정 관리 서비스 애플리케이션에 구글의 크리덴셜(Credential)이 직접적으로 제공되지 않기 때문에 일정 관리 서비스 애플리케이션에서 사용하는 크리덴셜(Credential) 저장소에 저장될 필요가 없으므로 사용자의 크리덴셜(Credential)을 이중으로 관리하지 않아도 됩니다.