OAuth2는 전통적으로 직접 작성한 서버에서 인증을 처리해주는 것과 달리, OAuth가 인증을 중개해 주는 메커니즘이다
보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜
즉, 이미 사용자의 정보를 가지고 있는 웹 서비스 (Google, Github 등)에서 사용자의 인증을 대신해주고, 접근 권한에 대한 토큰을 발급한 후 이를 이용해서 서버에서 인증이 가능해진다.
합당한 질문으로 그럼 이것을 왜 쓰냐는 질문이 나올수 있다
우리는 웹상에서 수없이 많은 서비스를 이용하고 각각의 서비스들을 이용하기 위해 회원가입 절차가 필요할때가 대부분이다, 그리고 그 모든 서비스에 ID와 Password를 기억하기도 쉽지않은 일이고 이에 OAuth를 활용한다면 자주 사용하고 중요한 서비스들 (Github, Goolge 등)의 ID 와 Password만 기억해놓고 해당 서비스들을 통해 소셜 로그인을 할 수 있다.
단순히 편의만을 위함이 아닌 보안에도 이점을 가지고 있다.
검증되지 않은 App에서 OAuth 를 사용해 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없으며, 인증 권한에 대한 허가를 미리 유저에게 구해야하기 때문에 더 안전하게 사용이 가능하다
Resource Owner : 액세스 중인 리소스의 유저
Clinet : Resource owner를 대신해 보호된 리소스에 액세스하는 응용프로그램
Resource server : client 의 요청을 수락하고 응답할 수 있는 서버
Authorization server : Resource server가 액세스 때 사용하는 자격 증명
Authorization Grant : 클라이언트가 액세스 토큰을 얻는 방법을 의미한다.
Authorization Code Grant Type : 권한 부여 승인 코드 방식 (중요)
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로,
가장 많이 쓰이고 기본이 되는 방식이며 리프레시 토큰이 사용 가능하다
Client Credentials Grant Type : 클라이언트 자격 증명 승인 방식
클라이언트가 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이어트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용이 가능하다, 이 방식은 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야하고, 리프레시 토큰 사용은 불가하다
Implicit Grant Type : 암묵적 승인 방식
별도의 권한 부여 승인 코드 없이 바로 액세스 토큰을 발급하는 방식이다.
이는 자격증명을 안전하게 저장하기 힘든 클라이언트 (자바스크립트 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식이며, 이 역시 리프레시 토큰은 사용 불가하다
또한 Authorization Server는 Client secret을 통해 클라이언트 인증 과정이 생략된 방식이기도 하다
Resource Owner Credentials Grant Type : 자원 소유자 자격증명 승인 방식
간단하기 로그인 시 필요한 정보(usernaeme,password)로 액세스 토큰을 발급하는 방식이다, 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로, 리프레시 토큰이 사용 가능하다.
예를 들자면, 카카오 계정으로 카카오 지도, 뱅크 등에 로그인하는 경우가 이 방식에 해당한다
요점은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템으로 속해 있을 때만 사용하는 방식
Authorization code : access token을 발급받기전에 필요한code
Access token : 보호된 리소스에 액세스하는데 사용되는 credentials
Scope : 주어진 액세스 토큰을 사용하여 액세스할 수 있는 리소스 범위이다
이와 같은 설정을 통해 특정 유저의 사진첩에는 접근할 수 있지만, 연락처 등 다른 리소스에는 접근할 수 없도록 접근 권한을 지정할 수 있다.