코드스테이츠 67-68일차

학습 목표

• OAuth2가 무엇인지 이해할 수 있다.
• OAuth2의 인증 방식을 설명할 수 있다.
• Authorization Code와 Access Token의 차이에 대해 이해할 수 있다.
• Authorization 서버와 Resource 서버의 차이에 대해 이해할 수 있다.
• Spring Security에서 OAuth를 구현할 수 있다.

나는 코드스테이츠에서 학습을 하며 매일 위 화면에서 로그인을 하여 출석을 한다.

카카오, 구글과 아무런 상관이 없는 별도의 서비스인데 어떻게 카카오와 구글 계정으로 로그인을 할 수 있는 걸까?

요즘 많은 서비스들이 구글, 카카오, 네이버 등의 계정을 통해 쉽게 회원가입과 로그인을 할 수 있도록 제공하고 있는데 서비스에 따라 회원관리 뿐만아니라 다른 SNS에 게시글을 게시하도록 하거나 회원 정보를 연동하기도 한다.

하지만 우리가 모르는 사이에 다른 서비스의 아이디와 비밀번호를 공유하고 있는게 아닐까? 하는 불안함이 있기도 할텐데

다행히도 우리는 OAuth 라는 기술을 통해 비밀번호를 제공하지 않고도 다른 서비스에 접근할 수 있다.

 

OAuth2 란?

우리가 웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2라는 기술을 바탕으로 구현한다.

전통적으로 직접 작성한 서버에서 인증을 처리해 주는 것과는 달리, OAuth는 인증을 중개해 주는 메커니즘인데 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜이다.

즉, 이미 사용자 정보를 가지고 있는 웹 서비스(GitHub, google, facebook 등)에서 사용자의 인증을 대신해 주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해진다.

하지만 OAuth 또한 여전히 사용자 정보가 내 서버에 저장되는 것은 변함이 없다.

OAuth는 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 순전히 내 서버의 몫이다.

 

OAuth 는 언제, 왜 쓸까?

유저 입장에서 생각해 보자면, 우리는 웹상에서 굉장히 많은 서비스를 이용하고 있고 각각의 서비스들을 이용하기 위해서는 회원가입 절차가 필요한 경우가 대부분이다.

서비스별로 ID와 Password를 다 기억하는 것은 매우 귀찮은 일인데 OAuth를 활용한다면 자주 사용하고 중요한 서비스들(예를 들어 google, github, facebook)의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있어 매우 편리해진다.

뿐만 아니라 OAuth는 보안상의 이점도 있는데, 검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다.

 

OAuth 용어

• Resource Owner: 액세스 중인 리소스의 유저이다. 김코딩의 구글 계정을 이용하여 App에 로그인할 경우, 이때 리소스 오너 김코딩이 된다.
• Client: 리소스 오너를 대신하여 보호된 리소스에 액세스하는 애플리케이션이다. 클라이언트는 서버, 데스크탑, 모바일 또는 기타 장치에서 호스팅할 수 있다. 김코딩이 A라는 애플리케이션을 Google의 소셜로그인을 이용해 사용한다면 A가 클라이언트가 된다.
• Resource Server: 클라이언트의 요청을 수락하고 응답할 수 있는 서버이다. 클라이언트(e.g. A 애플리케이션)가 Google Photo에서 김코딩의 사진을 가져오는 경우, Google Photo가 리소스 서버가 된다.
• Authorization Server: Resource Server가 액세스 토큰을 발급받는 인증 서버이다. 리소스 오너를 성공적으로 인증한 후 클라이언트에게 액세스 토큰을 발급하는 서버를 말한다.
• Authorization Grant: 클라이언트가 액세스 토큰을 얻는 방법을 의미한다. 다음과 같은 방법들이 주로 사용된다. (Ex. Authorization Code Grant Type, Client Credentials Grant Type, Implicit Grant Type, Resource Owner Credentials Grant Type)
• Authorization Code: Authorization Grant의 한 타입으로 액세스 토큰을 발급받기 위한 Code를 의미한다. Client ID로 이 Code를 받아온 후, Client Secret과 Code를 이용해 액세스 토큰을 받아올 수 있다.
• Access Token: 보호된 리소스에 액세스하는 데 사용되는 인증 토큰이다. Authorization Code와 Client Secret을 이용해 받아온 이 Access Token으로 이제 리소스 서버에 접근할 수 있다.
• Scope: Scope는 토큰의 권한을 정의한다. 주어진 액세스 토큰을 사용하여 액세스할 수 있는 리소스의 범위이다. 이와 같은 설정을 통해 특정 유저의 사진첩에는 접근할 수 있지만, 연락처 등 다른 리소스에는 접근할 수 없도록 접근 권한을 지정할 수도 있다.

 

권한 부여 방식에 따른 프로토콜(인증 방식)

1. Authorization Code Grant : 권한 부여 승인 코드 방식

• Authorization Code Grant는 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로, 가장 많이 쓰이고 기본이 되는 방식이다. 또한 리프레시 토큰이 사용 가능하다.
• 권한 부여 승인 요청시 응답 타입(response_type)을 code로 지정하여 요청한다.

1. Resource Owner(유저)는 Client(애플리케이션)에 소셜 로그인 버튼을 누르는 등의 서비스 요청을 보낸다.

2. Client는 Authorization Server에 Authorization Code를 요청한다. 이 때 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송한다.

3. 로그인 팝업을 통해 Resource Owner는 로그인을 진행한다.

4. 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에 전달한다. (이전에 요청과 함께 전달한 Redirect URI로 Code를 전달한다.)

5. Client는 전달받은 Authorization Code를 이용해 액세스 토큰 발급을 요청한다. 액세스 토큰을 발급할 땐 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, 액세스 토큰을 함께 전송한다.

6. 요청 정보를 확인한 후 Redirect URI로 액세스 토큰을 발급한다.

7. Client는 발급받은 액세스 토큰을 이용해 Resource Server에 자원을 요청한다.

8. 액세스 토큰을 확인한 후 요청 받은 자원을 전달한다.

 

2. Client Credentials Grant : 클라이언트 자격 증명 승인 방식

클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용이 가능하다.

1. Client가 Authorization Server로 액세스 토큰 요청

2. Authorization Server에서 Client로 액세스 토큰 전달

3. Client가 Resource Server로 자원 요청

4. Resource Server가 Client로 자원 전달

 

3. Implicit Grant : 암묵적 승인 방식

별도의 권한 부여 승인 코드 없이 바로 액세스 토큰을 발급하는 방식이다.

이는 자격증명을 안전하게 저장하기 힘든 클라이언트(자바스크립트 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식이다.
리프레시 토큰 사용이 불가능하며, 이 방식에서 Authorization Server는 client secret을 통해 클라이언트 인증과정을 생략한다.

권한 부여 승인 요청시 응답 타입(response_type)을 token으로 지정하여 요청한다.

1. Resource Owner(유저)는 Client(애플리케이션)에 소셜 로그인 버튼을 누르는 등의 서비스 요청을 보낸다.

2. Client는 Authorization Server에 접근 권한 요청을 한다. 요청과 함께 미리 생성한 Client ID, Redirect URI, 응답타입을 전송한다. (Authroization Code를 획득하기 위한 요청이 아니다.)

3. 로그인 팝업을 통해 Resource Owner는 로그인을 진행한다.

4. 로그인이 확인되면 Authorization Server는 Client에게 액세스 토큰을 전달한다.

5. Client는 액세스 토큰을 이용해 Resource Server에 자원을 요청한다.

6. 액세스 토큰을 확인한 후 요청 받은 자원을 전달한다.

 

4. Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식

• 간단하게 로그인시 필요한 정보(username, password)로 액세스 토큰을 발급받는 방식이다. 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로, 리프레시 토큰의 사용도 가능하다.
• 예를 들어 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인, 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우가 Resource Owner Password Credential Grant에 해당한다.
• 다시 말해 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때만 사용이 가능하다.

1. Resource Owner(유저)는 Client(애플리케이션)에 로그인 버튼을 누르는 등의 서비스 요청을 보낸다. 이 때 로그인에 필요한 정보(username, password)를 이용해 요청한다.

2. Client에서는 Resource Owner에게서 전달받은 로그인 정보를 통해 Authorization Server에 액세스 토큰을 요청한다. 미리 생성한 Client ID, 권한 부여 방식, 로그인 정보를 함께 전달한다.

3. 요청과 함께 온 정보들을 확인한 후 Client에게 액세스 토큰을 전달한다.

4. Client는 액세스 토큰을 이용하여 Resource Server에 자원 획득 요청을 보낸다.

5. 액세스 토큰을 확인한 후 요청 받은 자원을 전달한다.