Qt OAuth2 개요

OAuth2

RFC 6749 OAuth 2.0은 비밀번호와 같은 민감한 사용자 자격 증명을 노출하지 않고 리소스를 인증할 수 있는 인증 프레임워크를 정의합니다.

OAuth2 프레임워크는 여러 클라이언트 유형(공개 및 기밀)과 흐름(암시적, 인증 코드 및 기타 여러 가지)을 정의합니다. 일반적인 Qt 애플리케이션의 경우 클라이언트 유형은 공용 네이티브 애플리케이션으로 간주해야 합니다. 공개는 애플리케이션이 제공된 바이너리에 포함된 암호와 같은 비밀을 보유하는 것을 신뢰하지 않는다는 것을 의미합니다.

네이티브 앱용 RFC 8252 OAuth 2.0은 이러한 애플리케이션에 대한 모범 사례를 추가로 정의합니다. 무엇보다도 인증 코드 흐름을 권장 흐름으로 정의합니다. QtNetworkAuth 이 흐름에 대한 구체적인 구현을 제공하며 이 문서의 초점이기도 합니다.

Qt OAuth2 클래스

QtNetworkAuth 는 구체적인 클래스와 추상적인 OAuth2 클래스를 모두 제공합니다. 추상 클래스는 사용자 정의 플로우를 구현하기 위한 것이고, 구체 클래스는 구체적인 구현을 제공합니다.

QtNetworkAuth 로 OAuth2 플로우를 구현하려면 두 개의 클래스가 필요합니다:

• OAuth2 플로우 구현 클래스는 기본 API를 제공하며 플로우의 오케스트레이터 역할을 합니다. 일반적으로 하나의 응답 핸들러를 소유합니다. 추상 클래스는 QAbstractOAuth2 이며, 구체적인 구현은 QOAuth2AuthorizationCodeFlow 입니다.
• 권한 부여 서버의 응답을 처리하는 응답 처리기 클래스입니다. 권한 부여 코드 흐름에는 권한 부여, 액세스 토큰 요청 및 액세스 토큰 새로 고침이 포함됩니다. 응답 처리 결과는 플로우 클래스에서 추가로 처리합니다. 응답 처리기 추상 클래스는 QAbstractOAuthReplyHandler 이며, 구체적인 클래스는 QOAuthHttpServerReplyHandler 과 QOAuthUriSchemeReplyHandler 입니다.

권한 부여 코드 흐름

인증 코드 흐름은 Qt 애플리케이션과 같은 네이티브 애플리케이션에 권장되는 OAuth2 흐름입니다.

다음 코드 스니펫은 설정 예시를 제공합니다:

QOAuth2AuthorizationCodeFlow m_oauth;
QOAuthUriSchemeReplyHandler m_handler;
m_oauth.setAuthorizationUrl(QUrl("https://some.authorization.service/v3/authorize"_L1));
m_oauth.setAccessTokenUrl(QUrl("https://some.authorization.service/v3/access_token"_L1));
m_oauth.setClientIdentifier("a_client_id"_L1);
m_oauth.setScope("read"_L1);

connect(&m_oauth, &QAbstractOAuth::authorizeWithBrowser, this, &QDesktopServices::openUrl);
connect(&m_oauth, &QAbstractOAuth::granted, this, [this]() {
    // Here we use QNetworkRequestFactory to store the access token
    m_api.setBearerToken(m_oauth.token().toLatin1());
    m_handler.close();
});
m_handler.setRedirectUrl(QUrl{"com.my.app:/oauth2redirect"_L1});
m_oauth.setReplyHandler(&m_handler);

// Initiate the authorization
if (m_handler.listen()) {
    m_oauth.grant();
}

단계

권한 부여 코드 흐름에는 리소스 권한 부여(필요한 사용자 인증 포함)와 액세스 토큰 요청의 두 가지 주요 단계가 있습니다. 그 다음에는 선택적으로 액세스 토큰 사용 및 액세스 토큰 새로 고침이 이어집니다. 다음 그림은 이러한 단계를 보여줍니다:

• 권한 부여 단계에서는 사용자가 인증되고 사용자가 리소스에 대한 액세스를 승인합니다. 이를 위해서는 사용자의 브라우저 상호 작용이 필요합니다.
• 권한 부여 후에는 수신된 인증 코드를 사용하여 액세스 토큰을 요청하고 선택적으로 새로 고침 토큰을 요청합니다.
• 액세스 토큰이 획득되면 애플리케이션은 이를 사용하여 관심 있는 리소스에 액세스합니다. 액세스 토큰은 리소스 요청에 포함되며, 토큰의 유효성을 확인하는 것은 리소스 서버의 몫입니다. 토큰을 요청의 일부로 포함하는 방법에는 여러 가지가 있지만 HTTP Authorization 헤더에 토큰을 포함하는 것이 가장 일반적입니다.
• 액세스 토큰 갱신. 액세스 토큰은 일반적으로 1시간 이내에 비교적 빠르게 만료됩니다. 애플리케이션이 액세스 토큰과 함께 새로 고침 토큰을 받은 경우 새로 고침 토큰을 사용하여 새 액세스 토큰을 요청할 수 있습니다. 새로 고침 토큰은 수명이 길기 때문에 애플리케이션은 새 인증 단계(따라서 또 다른 브라우저 상호 작용)가 필요하지 않도록 토큰을 유지할 수 있습니다.

세부 사항 및 사용자 지정

OAuth2 흐름은 동적이며 처음에는 세부 사항을 따르기가 까다로울 수 있습니다. 아래 그림은 성공적인 인증 코드 흐름의 주요 세부 사항을 보여줍니다.

명확성을 위해 사용 빈도가 낮은 일부 신호는 생략했지만, 세부 사항과 주요 사용자 지정 포인트는 모두 설명되어 있습니다. 사용자 지정 포인트는 애플리케이션이 포착(및 호출)할 수 있는 다양한 신호/슬롯과 QAbstractOAuth::setModifyParametersFunction()로 설정 가능한 콜백입니다.

응답 핸들러 선택하기

어떤 응답 핸들러를 사용할지 또는 구현할지 결정하는 것은 사용된 redirect_uri에 따라 달라집니다. redirect_uri 은 인증 단계가 완료되면 브라우저가 리디렉션되는 곳입니다.

네이티브 애플리케이션의 맥락에서 RFC 8252는 세 가지 주요 유형의 URI 스키마를 설명합니다: loopback, https, 비공개 사용.

• 개인용 URI: OS에서 애플리케이션이 사용자 지정 URI 스키마를 등록하도록 허용하는 경우에 사용할 수 있습니다. 이러한 사용자 지정 스키마가 있는 URL을 열려고 하면 관련 기본 애플리케이션이 열립니다. QOAuthUriSchemeReplyHandler 을 참조하세요.
• HTTPS URI: OS에서 애플리케이션이 사용자 지정 HTTPS URL을 등록하도록 허용하는 경우에 사용할 수 있습니다. 이 URL을 열려고 하면 관련 기본 애플리케이션이 열립니다. 이 방식은 OS에서 지원하는 경우에 권장됩니다. QOAuthUriSchemeReplyHandler 을 참조하세요.
• 루프백 인터페이스: 일반적으로 데스크톱 애플리케이션 및 개발 중인 애플리케이션에 사용됩니다. QOAuthHttpServerReplyHandler 는 리디렉션을 처리할 로컬 서버를 설정하여 이러한 URI를 처리하도록 설계되었습니다.

선택은 다음과 같은 여러 요인에 따라 달라집니다:

• 인증 서버 공급업체에서 지원하는 리디렉션 URI. 지원은 공급업체마다 다르며 특정 클라이언트 유형 및 운영 체제에 따라 달라지는 경우가 많습니다. 또한 애플리케이션의 게시 여부에 따라 지원 여부가 달라질 수 있습니다.
• 대상 플랫폼에서 지원하는 리디렉션 URI 스키마.
• 애플리케이션별 사용성, 보안 및 기타 요구 사항.

RFC 8252에서는 다른 방법보다 보안 및 사용성 측면에서 이점이 있는 https 스키마를 사용할 것을 권장합니다.