OAuth2.0이란

OAuth 2.0의 개념과 목적

OAuth 2.0은 웹이나 모바일 애플리케이션 등에서 서드 파티 애플리케이션(Third-Party Application)이 사용자의 인증 정보를 안전하게 사용할 수 있도록 하는 인증 및 권한 부여 프레임워크입니다.

 

OAuth 2.0의 주요 목적은 사용자가 서드 파티 애플리케이션에게 자신의 인증 정보(아이디, 비밀번호 등)를 제공하지 않고도, 서드 파티 애플리케이션에서 사용자의 개인 정보(예: 이메일, 친구 목록 등)를 안전하게 이용할 수 있도록 하는 것입니다.

 

예를들면 B 회사가 Google Calendar API에 접근하기 위해 사용자의 Google ID와 비밀번호를 요구하지 않고도, Google에서 로그인을 처리하고, 사용자가 Google Calendar API에 대한 접근 권한을 부여한 후, B 회사가 해당 권한을 사용하여 Google Calendar API에 접근할 수 있습니다.

 

이를 위해서 OAuth 2.0에서는 B 회사가 Google에 대해 등록한 클라이언트 ID와 클라이언트 비밀번호를 사용하여 인증을 수행하고, 인증이 완료되면 access token을 발급받아서 API를 호출할 수 있습니다.

 

따라서 OAuth 2.0은 웹 기술에서 광범위하게 사용되고 있으며, 페이스북, 구글, 트위터, 깃허브 등 다양한 서비스에서 제공되고 있습니다. 이를 통해, 사용자는 각 서비스에서 다양한 서드 파티 애플리케이션을 사용하며, 자신의 개인 정보를 안전하게 관리할 수 있게 됩니다.

 

OAuth 2.0의 구성 요소

OAuth 2.0은 인증 및 권한 부여를 위한 프로토콜로서, 다음과 같은 4가지의 개념이 사용됩니다.

1. Resource Owner는 해당 리소스에 대한 접근 권한을 가지고 있는 사용자를 뜻합니다. 이 사용자는 일반적으로 서비스 제공자 혹은 소유자일 수 있습니다.
2. OAuth Client는 리소스 서버에 접근 권한을 얻기 위해 인증을 요청합니다.
3. Resource Server는 요청받은 리소스에 대한 접근 권한 검사 및 해당 리소스에 대한 API를 제공하는 서버를 뜻합니다. 클라이언트가 리소스에 접근하려는 경우, 리소스 서버는 클라이언트의 권한을 검사하고, 유효한 경우 해당 리소스를 반환합니다.
4. Auth server는 클라이언트의 인증 및 접근 권한 부여를 처리하는 서버를 말합니다. 클라이언트는 auth server를 통해 자신의 신원을 인증하고, 리소스 서버에서 접근할 수 있는 권한을 부여받습니다.

OAuth 2.0의 개념과 목적을 설명하면서 들었던 예시를 다시 보면 B회사의 APP을 사용하는 사용자가 Resource Owner, Google이 Resoure Server 및 Auth Server가 됩니다.

 

Authorization Code Grant의 인증 절차

Auth code 발급 과정

OAuth 2.0의 인증 코드 방식은 다음과 같은 과정으로 이루어집니다.

1. 사용자는 Client에게 구글 캘린터 리스트를 전달합니다.
2. Client는 Resource Owner가 Auth code를 요청할 수 있는 링크를 전달합니다.
3. Resource Owner는 해당 링크를 클릭하여 Auth server에 로그인을 시도합니다.
4. 로그인이 성공하면, Auth server는 Redirect URL로 Resource Owner를 이동시키고, 이 URL에는 Auth code가 포함되어 있습니다.

 

Access token 발급 과정

OAuth 2.0의 Authorization Code Grant 방식에서 Access Token을 발급받는 과정은 다음과 같습니다.

1. Client는 Redirect URL에 포함된 Authorization Code를 사용해 Auth Server에 Access Token 발급을 요청합니다.
2. Auth Server는 Client ID, Secret, Redirect URL, Resource Owner ID, 그리고 Authorization Code 정보를 확인합니다.
3. 인증 정보가 정확하다면, Auth Server는 Access Token을 발급합니다.
4. 발급된 Access Token을 사용하여 Resource Server에서 보호되고 있는 리소스에 접근할 수 있습니다.

 

Access token과 Refresh Token

Access token과 Refresh token은 OAuth2.0에서 사용되는 인증 토큰입니다.

 

Access token은 사용자가 인증 후에 발급되며, API를 호출할 때 인증 정보로 사용됩니다. 일반적으로 Access token은 유효 기간이 존재하며, 만료되면 다시 인증을 수행해야합니다.

 

Refresh token은 Access token의 만료 시간이 지나서 Access token을 갱신해야 할 경우에 사용됩니다. Refresh token은 Access token과 별도로 발급되며, 일반적으로 Access token과는 달리 더 긴 유효 기간을 가집니다. Refresh token을 사용하면 사용자는 다시 로그인하지 않고도 Access token을 자동으로 갱신할 수 있습니다.

 

일반적으로 Refresh token은 Access token보다 보안 수준이 높습니다. 따라서 Refresh token을 안전하게 저장해야하며, Access token과는 달리 보안을 강화하기 위해 암호화되어 저장될 수 있습니다.

 

아래의 그림은 리프레쉬 토큰을 이용해 access token을 발급받는 과정입니다.

f

 

Authorization Code Grant 방식의 장단점

장점

1. Access token이 브라우저를 거치지 않고 서버 사이드에서 안전하게 관리될 수 있기 때문에 보안성이 높습니다.
2. Authorization Code가 유출되더라도 이를 사용하여 Access Token을 얻으려면 추가적인 인증이 필요하기 때문에 안전합니다.
3. Refresh Token을 사용하여 Access Token의 만료 시간을 연장할 수 있어, 사용자가 자주 로그인하지 않아도 되는 편리함을 제공합니다.
4. Resource Owner의 사용자 정보가 외부에 노출되지 않아서 개인정보 보호에 우수합니다.

단점

1. Access Token을 발급 받기 위해 다단계로 인증과정을 거쳐야 하기 때문에 복잡하며, API 서버와 인증 서버의 별도 관리가 필요합니다.
2. 추가적인 요청과 응답이 필요하여 사용자 경험이 떨어질 수 있습니다.
3. 인증 서버와 API 서버가 분리되어 있어, 동시에 장애가 발생할 경우 사용자 인증 과정에서 문제가 발생할 수 있습니다.

결론

OAuth 2.0은 현대적인 인증 방식으로써, 서로 다른 웹 서비스 간의 인증을 효과적으로 수행할 수 있는 프로토콜입니다. 이를 활용하면, 사용자들은 하나의 ID와 비밀번호로 여러 개의 웹 서비스에 접속할 수 있으며, 웹 서비스 간의 연동도 보다 간편하게 이루어집니다.

 

하지만, OAuth 2.0도 보안 취약점을 가지고 있으므로, 이를 해결하기 위해 여러 가지 조치가 필요합니다. 예를 들어, 안전한 인증을 위해 HTTPS 프로토콜을 사용하고, access token의 유효 기간을 제한하는 등의 조치가 필요합니다.

 

따라서, OAuth 2.0을 안전하게 사용하기 위해서는 이를 적용하는 모든 웹 서비스에 대해 보안적으로 충분히 검토하고 적절한 보안 조치를 취해야 합니다. 이러한 노력이 미래의 보안 문제를 예방하는 데 큰 역할을 할 것입니다.