[Server] OAuth의 개념 및 프로세스

OAuth란?

먼저 OAuth의 정의부터 살펴보면 다음과 같다.

OAuth(”Open Authorization”)는 인터넷 사용자들이 비밀번호를 제공하지 않고,

다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을

부여할 수 있는 공통적인 수단으로 사용되는, 접근 위임을 위한 개방형 표준이다.

 

여러 웹을 살펴보다 보면 Google, Kakao, Naver 등 외부 소셜 계정을 기반으로

간편하게 회원가입 및 로그인을 할 수 있는 웹 애플리케이션이 많이 존재한다.

이를 통해 간편하게 로그인을 할 수 있고,

연동되는 외부 애플리케이션에서 제공하는 기능을 간편하게 사용할 수 있다는 장점도 존재한다.

예를 들어 Google로 소셜 로그인을 진행하면 Api를 통해

연동된 계정의 Google Calendar 정보를 가져올 수 있다.

이때 사용되는 프로토콜이 OAuth인 것이다.

 

 

OAuth 구성요소

OAuth의 구성요소를 살펴보면 다음과 같다.

• Resource Owner
  내가 개발하려는 서비스의 사용자이자, 리소스의 주인
  직접 인증 절차를 수행 ( 카카오, 네이버 로그인 )
  즉 Resource는 개인정보를 뜻하고 Resource Owner는
  웹 서비스를 이용하려는 유저를 뜻한다.
• Client
  자사 또는 개인이 개발하려는 애플리케이션 서버
   OAuth를 이용하여 Resource Server의 인가를 받아서
  해당 리소스를 이용하고자 하는 서비스
• Authorization Server
  권한을 부여해 주는 서버
  사용자는 해당 서버로 아이디, 패스워드를 넘겨서 Authorization Code를 발급받을 수 있다.
  Client는 이 서버로 Authorization Code를 넘겨 Token을 받을 수 있다.
  Google, Kakao, Naver 등의 회사 서버이다.
• Resource Server
  사용자의 개인정보를 가지고 있는 애플리케이션 서버
  이것도 또한 Google, Kakao, Naver 등의 회사 서버이다.
  Client는 위의 인증 서버를 통해 발급받은
  Token을 통해 사용자 개인정보를 응답받을 수 있다.
  실제로는 Authorization Server와 Resource Server는
  동일한 서버일 수도 있고, 다른 서버일 수도 있다.
• AccessToken
  자원에 대한 접근 권한을 나타내는 자격증명 토큰
• RefreshToken
  Client는 Authorization Server로부터
  AccessToken과 함께 만료시간이 비교적 긴 RefreshToken도 같이 부여받는다.
  AccessToken은 보안상의 이유로 만료시간이 짧기 때문에,
  시간이 얼마 지나지 않아 토큰이 만료될 경우 다시 로그인을 시도해야 한다.
  이때 RefreshToken을 통해 재검증을 하고, AccessToken을 재발급받도록 할 수 있다.

AccessToken과 RefreshToken에 대한 설명과 실제 예제는 아래 포스팅을 통해 참고할 수 있다.

[Server] What is JWT ( Json Web Token )

[Spring boot] Spring Security Jwt Rest Api 구현

 

 

OAuth의 프로세스

먼저 OAuth의 프로세스를 그림으로 살펴보면 다음과 같다.

과정은 복잡해 보이지만 절차대로 따라가다 보면 쉽게 파악할 수 있다.

 

먼저 Client ID / Client Secret / Redirect URI부터 설명하면 다음과 같다.

• Client ID
  • 내가 만들고 있는 서비스의 식별자
  • 노출되어도 상관없다.
• Client Secret
  • 내 서비스의 비밀번호
  • 노출되면 안 된다.
• Authorized Redirect URI
  • 리소스 서버가 권한을 부여하는 과정에서 클라이언트에 Authorized Code를 전달해 줄 주소 
  • 리소스 서버는 사전에 등록된 주소가 아닌 다른 주소로부터 요청이 들어오면 무시한다.

Client가 Resource Server를 이용하기 위해서는, 사전에 승인을 받아 놓아야 한다.

즉 Kakao Resource Server를 이용하기 위해서 Kakao Developer에서 

웹 애플리케이션을 등록하고, 해당 애플리케이션의 ID, Secret 값을 부여받는 것이다.

등록하는 방법은 서비스마다 다르지만,

공통적으로 Client ID, Client Secret, Authorized Redirect URI를 받는다. 

카카오 로그인을 연동하는 과정에서도 Client ID, Secret / Redirect URI를 발급 및 등록해줘야 한다.

이제 해당 프로세스 절차를 한 단계씩 자세히 살펴보면 다음과 같다.

 

 

1. 서비스 접근 및 이용

사용자는 나의 My Server 웹에 접속하여 소셜 로그인 버튼을 발견할 것이다. 

그리고 사용자는 소셜 로그인을 원한다면 해당 버튼을 클릭하게 될 것이다. 

2. Client ID / Client Secret / Redirect URI

Client ID / Secret / Redirect URL는 전부 개발자 Server ( Client ) 측에 저장되어 있으며,

Resouce owner는 이에 대한 정보를 알 필요가 없다.

Client 서버 개발자는 해당 properties들을 등록하고,

소셜 로그인에 대한 로직을 Server에 구현한 상태이다.

Resource owner는 소셜 로그인을 하고 싶다면 해당 버튼을 클릭하기만 하면 된다.

 

3. 로그인 페이지 요청 / Client ID / Client Secret / Redirect URI

사용자가 소셜 로그인 버튼을 누르게 되면

특정 Url이 해당 카카오, 네이버 서버 쪽으로 보내지게 된다. 

이는 사용자가 직접 카카오나 네이버로 이동해서 로그인을 입력해야 하지만,

해당 Url을 통해 대신 로그인 페이지로 이동하게 도와주는 것이다.

해당 Url에는 Redirect URI와 Client ID 등이 파라미터로 포함되어 있다.

요청으로 온 Redirect URI, Client ID, Client Secret 값을

Authroization Server에서 등록되어 있는 서비스 정보와 비교한다.

 

4~5. 로그인 페이지 제공 /  아이디 패스워드 입력

등록되어 있는 서비스 정보와 비교하여 일치한다면

Authorization Server로부터 전용 로그인 페이지로 이동하며, 사용자 Resource owner에게 보인다.

해당 로그인 페이지에서 사용자는 아이디와 패스워드 입력을 하여 로그인을 완료한다.

이때 Scope 승인 페이지가 사용자에게 제공될 수 있다.

Scope란 Client가 사용하고 싶은 사용자 정보에 대한 범위로,

Scope에 해당되는 권한을 Client에게 부여할 것인지

Resouce owner인 사용자에게 재차 확인하는 것이다.

 

6~7. Authorization Code 발급 / Redirect URI로 Client에게 전달

Authorization Server는 사용자가 입력한 아이디와 패스워드로 인증을 시도하고,

인증이 성공적이라면 Authorization Server도 Client에게 권한을 승인한다는 의미로,

Authrozation Code를 Redirect URL를 통해 사용자에게 응답해 준다.

사용자는 그대로 다시 Client Server에게 전달해 준다.

그렇다면 이제 개발자 서버에게 권한 승인의 Code가 발급된 것이다.

 

8~9~10. AccessToken 요청 및 발급 / 로그인 완료

이제 개발자 서버 Client는 Authorization Code를 통해

Authorization Server에게 AccessToken을 발급 요청을 한다.

그리고 Authorization Server는 해당 Code가 유효하다면 AccessToken을 발급해 주고,

토큰을 받은 Client는 로그인을 완료되었다고 사용자에게 응답할 수 있다.

그리고 AccessToken을 데이터베이스에 저장한 후,

저장된 AccessToken을 이용하여 API를 Resouce Server에 보낼 수 있는 것이다.

 

11~14. AccessToken을 이용한 API 호출

Client 개발자 서버는 데이터베이스에 저장되어 있는 AccessToken에 접근하여,

Resource Server에게 API를 요청하여 Resource owner (실제 사용자)의

ID 혹은 이메일, 프로필 정보 등에 접근하여 사용할 수 있다.

하지만 한 가지 고려할 것이 RefreshToken이다. 위에서 설명한 것처럼

만료시간의 차이가 있는 두 개의 토큰을 Authorization Server에서 제공하는 경우가 많다.

따라서 AccessToken이 만료되었을 경우 RefreshToken을 통해

AccessToken을 재발급받아야 하는 경우가 있다.

 

15. RefreshToken을 통해 AccessToken 재발급

만약 AccessToken이 기간이 만료되어 Resource Server에서 401 응답을 받는다면,

RefreshToken을 통해 AccessToken을 재발급받아야 한다.

즉 Authorization Server에게 AccessToken과 RefreshToken을 2개 발급한다면

두 개의 정보를 모두 Client에 저장해야 한다. 이때 일반적인 관계형 데이터베이스를 이용해도 되고,

Redis Key-Value 데이터베이스를 이용해도 된다. 이를 구현하는 방법은 여러 가지 존재할 수 있다.

 

 

 

지금까지 OAuth의 기본 개념 및 절차에 대해 살펴보았다.

OAuth의 프로세스에는 토큰 기반 인증이 포함되어 있고,

이를 통해 Client 서버를 구축 시 토큰에 대한 접근 및 저장을 구현해야 할 필요가 있다.

Spring boot에서는 OAuth Client Provider라는 것이 존재하여

Authorization Code를 통해 AccessToken을 발급받은 후

바로 사용자 프로필이나 정보에 접근할 수 있는 방법도 존재한다.

다음 포스팅에서는 OAuth2 Client 의존성을 사용하여 소셜 로그인을 구현해 볼 것이다.

 

 

 

참고자료

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

https://engineerinsight.tistory.com/163