[네트워크]OAuth

LMH·2023년 1월 9일

네트워크

이번 포스팅에서는 OAuth에 대한 개념을 정리하겠습니다.

OAuth란?

OAuth는 인증을 위한 개방형 표준 프로토콜입니다. Third-Party 프로그램에게 리소스 소유자(사용자)를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공합니다.

예시로, 현재 많은 웹 페이지에서 소셜 로그인 인증방식을 지원하고 있습니다. 네이버, 카카오, 구글 등에 가입되어있는 경우 복잡한 회원가입 절차 없이 쉽게 새로운 웹 페이지에 접근할 수 있습니다.

OAuth는 소셜 로그인 인증 방식(매커니즘)입니다. 리소스 소유자, 접근하고자 웹 페이지, 사용자의 정보를 가지고 있는 소셜 서비스 간의 중개자 역할을 합니다.

기존에 사용자의 정보를 가지고 있는 서비스에서 사용자 인증을 대신해주고 접근 권한에 대한 토큰을 발급합니다. 그리고 그 토큰을 이용하여 사용자는 새로운 웹 페이지에 접근할 수 있습니다.

OAuth 1.0 vs OAuth 2.0

OAuth 1.0

OAuth 1.0이 생겨나게 된 배경은 사용자 인증의 간편함과 개인정보 관리 문제입니다. 과거에는 사용자들이 여러 웹 사이트에 회원가입을 할 때마다 개인정보를 입력해야 했고 많은 사이트에 가입되어 있을수록 개인정보 유출에 대한 걱정이 클 수 밖에 없었습니다.

OAuth 1.0은 사용자, 소비자(접근하려는 웹 사이트), 서비스 제공자(소셜 서비스) 간에 인증 토큰 전달 방식을 통한 간편한 로그인을 지원하였습니다.

OAuth 2.0

OAuth 1.0의 복잡한 기능을 단순화하고 HTTPS 프로토콜을 필수적으로 사용하면서 암호화가 강화되었습니다. 그리고 기존 OAuth 1.0에서 지원하던 한 가지 인증방식에서 여러가지 인증방식을 지원하게 되었습니다.

OAuth 2.0 인증 종류

OAuth 2.0에서는 다음과 같은 인증 방식이 있습니다.

Authorization Code(인증코드 부여 방식)

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식입니다. 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다. Refresh Token의 사용이 가능한 방식입니다.

인증 코드 부여 방식은 웹 및 모바일 앱에서 사용되며, 인증 흐름은 다음과 같습니다.
1. 어플리케이션이 브라우저를 열어 사용자를 OAuth 서버로 보냅니다.
2. 사용자는 인증 프롬프트를 보고 앱의 요청을 승인합니다.
3. 사용자는 쿼리 문자열에 인증 코드가 있는 애플리케이션으로 다시 리디렉션됩니다.
4. 애플리케이션이 인증 코드를 액세스 토큰으로 교환합니다.

Implicit Grant(암묵적 승인 방식)

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식입니다.

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됩니다. Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험을 줄일 필요가 있습니다.

Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않습니다. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있습니다.

권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청합니다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력하게 되며 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달합니다.

Resource Owner Password Credentials Grant │ (자원 소유자 자격증명 승인 방식)

간단하게 username, password로 Access Token을 받는 방식입니다. 클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됩니다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다. Refresh Token의 사용도 가능합니다.

위와 같이 흐름은 간단합니다. 제공하는 API를 통해 username, password을 전달하여 Access Token을 받는 것입니다. 중요한 점은 이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이라는 점입니다.

Client Credentials Grant(클라이언트 자격증명 승인 방식)

클라이언트의 자격증명만으로 Access Token을 획득하는 방식입니다.

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.

이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없습니다.

OAuth 2.0 주요 용어

Resource Owner: 사용자이며 정보 제공자이기도 하기 때문에 Resource Owner라고 합니다.
Client: Resource Owner를 대신하여 보호된 리소스에 액세스하는 애플리케이션입니다.
Local Server: Client의 요청을 수락하고 응답할 수 있는 서버입니다.
Resource Server: 사용자의 정보를 저장하고 있는 서버입니다.
Authorization Server: 인증을 담당하고 있는 서버입니다. Access Token을 발급하는 인증 서버입니다.
Authorization Code: Authorization Grant의 한 타입으로 Access Token을 발급받기 위한 Code를 의미합니다.
Access Token: 보호된 리소스에 액세스하는 데 사용되는 인증 토큰입니다. 이 Access Token으로 이제 Resource Server에 접근할 수 있습니다.
Refresh Token: 발급받은 Access Token이 만료될 시 Refresh Token을 통해 새로운 Access Token을 받급받을 수 있습니다.