OAuth 2.0
📌 OAuth 2.0 등장 배경
사용자는 자신의 개인 정보를 누군가에게 맡기는 것이 부담되고 안전하지 못하다고 느낄 것이다. 구글, 페이스북, 트위터와 같은 대형 플랫폼도 마찬가지다. 그래서 사용자는 비밀번호를 주기적으로 바꾸고, 또 이런 것을 권장한다.
사용자가 제3의 서비스를 이용한다면 사용자도 자신의 정보를 관리해야 하지만 이를 제3의 서비스 업체에서도 직접 저장하고 관리해야 한다. 이처럼 양쪽 모두의 부담을
덜기 위해 등장한 방법이 대형 플랫폼에 저장된 사용자 정보를 이용하자는 것이다.
하지만 대형 플랫폼에서도 사용자 개인 정보를 신뢰할 수 없는 제3의 서비스에 맡기는 것에 부담을 느낄 것이다. 따라서, 이러한 문제를 해결하면서 표준화된 방법이
필요해졌는데 이것이 OAuth의 등장 배경이 되었고, 좀 더 안전하고 단순화한 버전이 OAuth 2.0이다.
📌 OAuth 란?
구글, 페이스북, 트위터와 같은 다양한 플랫폼에 저장된 사용자의 데이터에 접근하기 위해 제3자 클라이언트가
접근 권한을 해당 플랫폼으로부터 위임받을 수 있는 표준 프로토콜
📌 OAuth 2.0 주체
✅ Resource Owner
다양한 플랫폼 및 제3자 클라이언트의 서비스를 이용하는 사용자를 말한다. 여기서 리소스는 친구 목록 및 작성한 게시글 목록 등이 있다.
✅ Authorization & Resource Server
Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급하는 서버다.
Resource Server는 구글, 페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 말한다.
✅ Client
Resource Server의 자원을 이용하고자 하는 서비스, 즉 제3자 클라이언트를 말한다.
📌 애플리케이션 등록
OAuth 2.0 서비스를 이용하기 전에 선행되어야 등록 과정이 있다.
✅ Redirect URI
Client를 Resource Server에 등록하기 위해 등록해야 하는 정보로, 사용자가 OAuth 2.0 서비스에서 인증을 마치고 사용자를 리다이렉션 시킬 위치를 말한다.
OAuth 2.0 서비스는 인증이 성공한 사용자를 사전에 등록된 Redirect URI로만 리다이렉션 시킨다. 이는 승인된 URI로만 이동시켜 Authorization Code를
탈취당하지 않기 위함이다.
Redirect URI는 기본적으로 보안을 위해 https만 허용한다. 단, 루프백(localhost)은 예외적으로 http가 허용된다.
✅ Client ID, Client Secret
등록 과정을 마친 후 얻을 수 있는 정보로, Client가 이후 액세스 토큰을 획득하기 위해 사용한다.
Client ID는 공개되어도 괜찮지만, Client Secret은 절대 유출되어서는 안 된다.
📌 OAuth 2.0 동작 메커니즘
✅ 로그인 요청
Resource Owner(사용자)는 Client(제3자 클라이언트, 타사 서비스)의 '구글로 로그인하기' 등의 버튼을 클릭하여 로그인을 요청한다. Client는 OAuth 프로세스를
시작하기 위해 사용자의 브라우저를 Authorization Server로 보내야 한다.
이때 Client는 Authorization Server가 제공하는 Authorization URL에 response_type, client_id, redirect_uri, scope 등의 매개변수를 쿼리 스트링에
포함하여 보낸다.
response_type: 반드시 code로 값을 설정해야 한다.
client_id: 애플리케이션을 생성했을 때 발급받은 Client ID
redirect_uri: 애플리케이션을 생성할 때 등록한 Redirect URI
scope: 클라이언트가 부여받은 리소스 접근 권한
✅ 로그인 페이지 및 ID/PW 제공
Client가 빌드한 Authorization URL로 이동된 Resouce Owner는 제공된 로그인 페이지에서 ID와 PW 등을 입력하여 인증 시도
✅ Authorization Code 발급 후 Redirect URI로 리다이렉트
인증이 성공했다면, Authorization Server는 Redirect URI에 Authorization Code를 포함하여 사용자를 리다이렉션 시킨다. 구글의 경우 코드를 쿼리 스트링에
포함한다.
💡 Authorization Code
Client가 Access Token을 획득하기 위해 사용하는 임시 코드 (일반적으로 1 ~ 10분의 수명)
✅ Authorization Code와 Access Token 교환
Client는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답받는다. Client는 발급받은 Resource Owner의 Access Token을
저장하고, 이후 Resource Server에서 Resource Owner의 리소스에 접근하기 위해 사용한다.
Access Token은 유출되어서는 안 되기 때문에 https 연결을 통해서만 사용될 수 있다.
Authorization Code와 Access Token 교환은 token 엔드포인트에서 이루어지며 application/x-www-form-urlencoded의 형식에 맞춰 전달해야 한다.
💡 HTTP 요청 시, 필수로 전달해야 할 매개변수
grant_type: 항상 authorization_code로 설정되어야 한다.
code: Authorization Code
redirect_uri: Redirect URI
client_id: Client ID
client_secret: RFC 표준상 필수는 아니지만, Client Secret이 발급된 경우 포함하여 요청해야 한다.
✅ 로그인 성공
위 과정을 성공적으로 마치면 Client는 Resource Owner에게 로그인 성공을 알린다.
✅ Access Token으로 리소스 접근
Resouce Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 앞서 발급받았던 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사의 서비스를 제공한다.
🔍 OAuth 2.0의 Scope
OAuth 2.0은 Scope라는 개념을 통해서 사용자 리소스에 대한 Client의 접근 범위를 제한할 수 있다. Scope는 여러 개가 될 수 있으며, 대소문자를
구분하는 문자열을 공백으로 구분하여 표현한다. 이때 문자열은 OAuth 2.0 인증 서버에 의해 정의된다.
예를 들어 Client는 Scope에 필요한 사용자 리소스를 OAuth 2.0 스코프에 문자열로 명시하고 OAuth 2.0 제공자에게 전달한다. 그러면 사용자는
Scope에 명시된 권한을 요청하는 화면을 만날 것이다. 사용자가 권한을 허용하면, Client는 Access Token을 통해 제한된 리소스를 Resource Server에서 얻을 수 있다.
🔍 Authorization Code를 발급하는 이유
Authorization Code를 발급하지 않으면, Authorization Server가 Client에게 Access Token을 전달할 방법은 Redirect URI 밖에 없다. Redirect URI는 URL 자체에 데이터를 실어 전달하기 때문에 브라우저를 통해 데이터가 곧바로 노출된다. 이를 방지하기 위해 Authorization Code를 사용하는 것이다.
보통 Redirect URI를 프론트엔드 주소로 설정하여 Authorization Code를 프론트엔드로 보낸 후 프론트엔드는 이를 백엔드로 보낸다. 전달받은 백엔드는 Authorization Code를 통해 Authorization Server에 token 엔드포인트로 Access Token을 요청하는 식으로 동작한다. 이렇게 하면 Access Token은 제3자 클라이언트의 애플리케이션과 OAuth 서비스의 백엔드 채널을 통해서만 전송되므로 Access Token을 안전하게 관리할 수 있다.
Reference:
OAuth 2.0 개념과 동작원리
2022년 07월 13일에 작성한 글을 보충하여 새로 포스팅한 글이다. OAuth 등장 배경 우리의 서비스가 사용자를 대신하여 구글의 캘린더에 일정을 추가하거나, 페이스북, 트위터에 글을 남기는 기능을
hudi.blog