OAuth 2
Open Authorization 2.0
OAuth 2 인증방식
:사용자가 특정 서비스를 이용하기 위해 신뢰할만한 벤더에게 대신 인증 처리를 위임하는 방식
전통적으로 특정 애플리케이션의 서비스를 이용하는 사용자에 대한 인증 처리는 해당 서비스를 직접적으로 제공하는 애플리케이션에서 담당함
인증 서버를 별도로 분리해서 인증을 처리하든 하나의 서버에서 사용자의 인증도 처리하고, 동시에 애플리케이션의 서비스도 함께 제공하든 어쨋든
서비슨를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜Credential을 직접 관리하는 것이 일반적임
그러나 OAuth 2는 다름
if.
사용자의 일정 관리 서비스를 제공하는 애플리케이션에서 사용자에게 캘린더 형태의 서비스를 제공하기위해 google의 calender API 이용 기능이 추가되었음
이 경우 일정 관리 서비스에 대한 회원가입을 통해 사용자의 크리덴셜을 관리해야함+ google calender API를 이용하기 위해 google에서 사용하는 사용자의 크리덴셜까지 일정 관리 서비스와 공유해야 함
이때 발생하는 문제점
-사용자에게 가장 중요한 정보인 크리덴셜을 2개 관리해야함
-구글 사이트에서 패스워드 변경 시, 변경된 구글 패스워드를 일정 관리 서비스 애플리케이션에서 추가로 업데이트해야함
-일정 관리 애플리케이션이 구글 사이트에서 사용하는 크리덴셜을 직접적으로 가지고 있음
보안 침해 사고 발생 시 심각한 피해 발생 가능
-문제 보안하는 방법->
구글에서 사용하는 사용자의 크리덴셜을 일정 관리 서비스 애플리케이션에서 직접 관리하지 않으면서도 구글 캘린더 API를 이용할 수 있게 함
OAuth2
:특정 애플리케이션/클라이언트에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드파티 애플리케이션에서 사용자의 인증을 대신 처리해주고
:Resource에 대한 자격 증명용 토큰을 발급한 후
:클라이언트가 해당 토크을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식
즉
일정관리 서비스 애플리케이션을 사용하는 사용자의 구글 전용 크레덴셜이 일정관리 서비스 애플리케이션에 직접적으로 제공되지 않아도 됨(=일정관리 서비스 애플리케이션이 구글 크레덴셜을 저장하지 않으므로 사용자의 크레덴셜을 이중으로 관리하지 않아도 됨 =보안성 향상)
OAuth 2 사용하는 애플리케이션 유형
1 써드파티 애플리케이션에서 제공하는 API의 직접적인 사용
구글 깃헙 페이스북 같은 신뢰할만한 써드파티 애플리케이션에서 제공하는 API를 직접적으로 사용하는 애플리케이션을 구현하는데 OAuth 2 사용 가능
사용자가 OAuth 2 인증 프로토콜을 이용해 써드파티 애플리케이션에 대한 인증에 성공하면 써드파티 애플리케이션에서 제공하는 API 를 활용한 커스텀 서비스를 제공하는 것
2 추가적인 인증 서비스 제공 용도
써드파티 애플리케이션의 서비스 이용 및 추가적인 인증 서비스를 제공하기 위한 용도
