Spring Security OAuth 2.0를 이해해보자

OAuth란?

게임이나 쇼핑몰 같은 웹사이트를 이용하다보면  [Google로 간편 로그인], [NAVER로 간편 로그인] 등과 같이 타 서비스의 계정으로 로그인할 수 있도록 구현된 것을 확인할 수 있습니다. 타 서비스의 계정을 통해 로그인하는 기능을 구현하는 가장 쉬운 방법은 구현하고자 하는 웹 사이트에서 Google이나, NAVER의 아이디나 비밀번호를 요청하여 제공받고, 이를 저장하여 사용하는 방법일 것입니다. 하지만 이런 방법은 보안상으로 좋지 않은 방법입니다. 사용자들은 가입하고자 하는 웹 사이트에 자신의 Google이나 NAVER 계정 정보를 줘야하고, Google이나 NAVER 입장에서도 자신이 갖고 있는 사용자의 정보를 다른 웹 사이트에 공유한다는 것이 부담스럽기 때문입니다. 

 

이를 해결하고자 Google 같은 곳에선 아이디와 비밀번호를 제공받지 않더라도, 접근 권한을 위임받을 수 있는 방식을 개발하였습니다. 하지만 각 서비스 업체(Google, ...)에서 개별적으로 개발을 했기 때문에 소셜 로그인을 구현하려는 웹 사이트에서는 각각의 방식을 알아야하는 번거로움이 있었습니다. 이런 불편함을 해소하기 위해 OAuth 1.0이 개발되었고, 이를 개선하고 확장하여 OAuth 2.0이 나왔습니다.

 

정리하자면 OAuth는 사용자의 리소스에 대한 안전하고 제한된 접근을 가능하게 하는 개방형 표준 인증 프로토콜입니다. 즉, OAuth는 사용자의 비밀번호를 공유하지 않고도 사용자의 타 서비스 업체 정보의 권한을 타 서비스 업체로부터 위임받는 것입니다.

---

OAuth 2.0 용어 정리

• `Resource Owner`: 사용자 (Client가 제공하는서비스를 이용하고자 하는)
• `Client`: 자원에 접근 요청하는 어플리케이션, 개발하려고 하는 서비스
• `Resource Server`: 데이터를 가진 서버. 예) Google, NAVER 등
• `Authorization Server`: 인증 담당 서버로 `Resource Owner`를 인증하고, `Client`에게 `Access Token` 발급

위에서 `Resource Server`와 `Authorization Server`를 분리하여 설명하였지만 통칭으로 `Resource Server`라고 아래에 설명하겠습니다.

 

• Authentication: 인증, 접근 자격이 있는지 검증하는 단계
• Authorization: 인가, 자원에 접근할 권한을 부여. 이 단계를 통해 접근 권한이 담긴 `Access Token` 발급

---

OAuth 2.0 작동 순서: 소셜 로그인 예제

출철: PAYCO

1~2. Client 등록

OAuth 2.0을 사용하기 위해선 일단 `Client` 어플리케이션을 OAuth 2.0 제공자인 `Resource Server`에 등록해주어야 합니다. 등록해줄 때 `Redirect URI`를 포함한 정보들을 입력해주어야 합니다. 

등록을 완료하면 `Client ID`와 `Client Secret`을 발급받습니다.

 

• `Redirect URI`: 사용자가 OAuth 2.0 서비스 인증을 마쳤을 때 사용자를 redirection시킬 URI 입니다. 승인되지 않은 URI로 redirection될 경우, `Authorization Code`를 탈취 당할 위험성이 있기 때문에 `Redirect URI`를 지정해줍니다.
• `Client ID`와 `Client Secret`: `Access Token`을 발급받는데 사용됩니다. `Client Secret`이 유출되지 않도록 주의해야 합니다.

 

3. Resource Owner 로그인 요청

`Resource Owner`가 [Google로 간편 로그인]을 클릭하여 요청합니다.
`Client`가 `Resource Server`로 로그인 요청을 할 때 `Client ID`, `Redirect URI`, `Response Type`, `Scope` 등을 보냅니다.

• `Client ID`와 `Redirect URI`: `Resource Owner`가 보낸 `Client ID`와 `Redirect URI`를 `Resource Server`에서 같은지 확인합니다.
• `Scope`: `Client`가 접근할 수 있는 자원 권한.
• `response_type`: `Client`가 OAuth 인증 서버로부터 어떤 유형의 응답을 받을지 지정합니다.
  • `code`: `Authorization Code Grant` 플로우를 사용, 인증 서버는 Authorization Code를 발급하여 Client에게 전달하고, Client는 Authorization Code를 사용하여 Access Token을 요청합니다.   
  • `token`: `Implicit Grant` 플로우를 사용, 인증 서버는 Access Token을 직접 Client에게 반환합니다. Client가 별도의 인증 코드 없이 Access Token을받을 수 있게 합니다.  

예제는 `response_type=code`로 설명하겠습니다.

Authorization Code  ⭐ ⭐
기본 방식으로 두 단계 인증 프로세스로 구성되어 있습니다. 리소스 서버로부터 받은 인증 코드를 사용하여 액세스 토큰을 요청합니다. 

Implicit Grant
단일 단계 인증 프로세스로 구성되어 있습니다. 리소스 서버로부터바로 액세스 토큰을 발급 받습니다. 때문에 Authorization Code 방식에 비해 보안성이 상대적으로 낮을 수 있습니다.

왜 보안성이 낮다는 걸까?  
Redirect URI를 통해 Authorization Code를 발급하지 않고 바로 Access Token을 발급한다고 생각해보자. 그럼 Authorization Server가 Access Token을 Client에게 전달하기 위해 Redirect URI에 Access Token을 담아 전달 한다. 즉, URL 자체에 데이터를 실어 전달한다는 말이다. 그럼 데이터가 노출되기 때문에 보안상으로 취약하다.

Authorization Code를 사용하는 흐름을 생각해보자. Redirect URI를 통해 Authorization Code를 전달한다. 이때 보통 Redirect URI는 Front-End 주소로 설정한다. 따라서 이 Authorization Code가 Front-End로 전달되고 Access Token을 요청하려할 때 Front-End는 Back-End로 Authorization Code를 전달하고 Code를 전달받은 Back-End는 Authorization Server에 요청을 하여 Access Token을 발급 받는다. 이러한 과정으로 보안상으로 유리하다.  

 

4~5. 로그인 인증

로그인 요청이 승인되면, Resource Owner는 출력된 로그인 페이지에서 ID와 비밀번호를 입력하여 인증합니다.

 

6~7. Authorization Code 발급

로그인 인증을 성공하면, Authorization Server는 Client에게 `Authorization Code`를 발급해주는데, Client의 권한도 승인하기 위해 Redirect_URI에 `Authorization Code`를 담아 사용자를 통하여 Client에게도 전달되게 합니다.

 

8~9. Access Token 발급

Client가 Authorization Code를 이용하여 Access Token을 발급 받습니다. AccssToken을 발급받은 Client는 이를 DB에 저장합니다.

 

10~14. Access Token을 이용하여 Resource Server 서비스 이용

Client가 발급받은 Access Token을 이용하여 Resource Server의 자원을 요청할수 있습니다.  또한 Resource Owner에 대한 인증도 Resource Server를 통해 한 셈이기 때문에 Resource Owner는 Client의 서비스를 이용할 수가 있습니다.