주제
OAuth2.0 학습
목표
•
OAuth2.0의 정의에 대해서 안다
•
OAuth2.0의 인증 흐름에 대해서 안다
키워드
OAuth2.0 | resource owner | resource server | client |
role | grant | third-party | authorization-server |
access-token | flow | refresh-token | credential |
정리
정의
애플리케이션이 계정정보를 직접 가지지 않고 허용된 자원에 접근할 수 있게 해주는 인증 프로토콜
기존 문제점
서버의 자원을 가져오려면 자원 소유자의 계정정보(credential)을 사용해야 한다.
다른 Third party 애플리케이션에서도 자원에 접근하려면 자원 소유자의 계정 정보를 공유해야 한다
1.
Third party 애플리케이션이 계정정보를 저장
2.
서버가 비밀번호 인증을 지원해야한다
3.
Third party 애플리케이션이 많은 권한을 가짐(계정정보를 가지고 있으므로)
4.
자원 소유자가 Third party 애플리케이션에 대해 엑세스를 취소할 수 없다(비밀번호를 변경하지 않는 이상)
5.
Third party 애플리케이션의 계정정보가 탈취되면 전체 데이터가 손상될 수 있다
근본적으로 원래 application의 계정정보가 third-party 애플리케이션과 공유되는 것이 문제
해결 방법
인증/인가 레이어를 두어 계정정보가 third-party 애플리케이션에 저장되는 일이 없도록 한다
구성요소
•
resource owner
◦
리소스에 대해 권한을 줄 수 있는 개체
•
resource server
◦
리소스를 가지고 있는 서버
◦
access token을 확인하여 요청에 응답
•
client
◦
리소스 소유자를 대신하여 리소스를 요청하고 승인 받은 애플리케이션
•
authorization server
◦
리소스 소유자를 인증하고 권한을 얻은후 클라이언트에게 액세스 토큰을 발행하는 서버
인증 흐름
대략적인 흐름은 아래와 같다(상세한 내용은 다른 블로깅에서 진행하겠다)
1.
클라이언트는 리소스 소유자에게 인가 요청을 보낸다(구글로 로그인하기 버튼을 누르면 나오는 페이지)
2.
리소스 소유자는 권한을 준다(구글로 로그인 하기 페이지에서 확인 버튼 클릭)
3.
클라이언트는 인가 서버에게 가서 Access token을 요청한다
4.
인가 서버는 Client에게 Access token을 발급해준다
5.
클라이언트는 Access token을 가지고 리소스 서버에 가서 리소스를 요청한다
6.
리소스 서버는 요청한 자원에 대해 응답한다
참조
다음 질문
좀더 상세한 인증흐름에 대해서 알아보자