계정 연결 역할

C2C 커넥터를 생성하려면 OAuth 2.0 권한 부여 서버 및 계정 연결이 필요합니다. 자세한 내용은 계정 연결 워크플로 단원을 참조하십시오.

OAuth 2.0은 계정 연결을 구현할 때 다음 네 가지 역할을 정의합니다.

1. 권한 부여 서버

2. 리소스 소유자(최종 사용자)

3. 리소스 서버

4. 클라이언트

다음은 이러한 각 OAuth 역할을 정의합니다.

권한 부여 서버

권한 부여 서버는 타사 클라우드에서 최종 사용자의 자격 증명을 식별하고 인증하는 서버입니다. 이 서버에서 제공하는 액세스 토큰은 AWS 최종 사용자의 고객 플랫폼 계정과 타사 플랫폼 계정을 연결할 수 있습니다. 이 프로세스를 계정 연결이라고 합니다.

권한 부여 서버는 다음을 제공하여 계정 연결을 지원합니다.

• 최종 사용자가 시스템에 로그인할 수 있는 로그인 페이지를 표시합니다. 이를 일반적으로 권한 부여 엔드포인트라고 합니다.

• 시스템의 최종 사용자를 인증합니다.

• 최종 사용자를 식별하는 권한 부여 코드를 생성합니다.

• AWS IoT Device Management의 관리형 통합에 권한 부여 코드를 전달합니다.

• AWS IoT Device Management의 관리형 통합에서 권한 부여 코드를 수락하고 AWS IoT Device Management의 관리형 통합이 시스템의 최종 사용자 데이터에 액세스하는 데 사용할 수 있는 액세스 토큰을 반환합니다. 이는 일반적으로 토큰 URI 또는 엔드포인트라는 별도의 URI를 통해 완료됩니다.

중요

권한 부여 서버는 AWS IoT Device Management Connector용 관리형 통합과 함께 사용할 OAuth 2.0 권한 부여 코드 흐름을 지원해야 합니다. AWS IoT Device Management용 관리형 통합은 코드 교환용 증명 키(PKCE)를 통한 권한 부여 코드 흐름도 지원합니다.

권한 부여 서버는 다음 중 하나를 수행해야 합니다.

• JWT 토큰과 같이 추출 가능한 최종 사용자 또는 리소스 소유자 ID가 포함된 액세스 토큰 발급

• 발급된 각 액세스 토큰에 대한 최종 사용자 ID를 반환할 수 있어야 합니다.

그렇지 않으면 커넥터가 필요한 AWS.ActivateUser작업을 지원할 수 없습니다. 이렇게 하면 관리형 통합에서 커넥터 사용을 방지할 수 있습니다.

커넥터 개발자 또는 소유자가 자체 권한 부여 서버를 유지 관리하지 않는 경우 사용되는 권한 부여 서버는 커넥터 개발자 타사 플랫폼에서 관리하는 리소스에 대한 권한을 제공해야 합니다. 즉, 권한 부여 서버에서 관리형 통합으로 수신한 모든 토큰은 디바이스(리소스)에 의미 있는 보안 경계를 제공해야 합니다. 예를 들어 최종 사용자 토큰은 다른 최종 사용자 디바이스에서 명령을 허용하지 않습니다. 토큰에서 제공하는 권한은 플랫폼 내의 리소스에 매핑됩니다. Lights™ 예제를 생각해 보세요. 최종 사용자가 커넥터와 계정 연결 흐름을 시작하면 권한 부여 서버 앞에 있는 Lights™ 로그인 페이지로 리디렉션됩니다. 로그인하고 클라이언트에 권한을 부여한 후에는 커넥터에 Lights™ 계정 내의 리소스에 대한 액세스 권한을 부여하는 토큰을 제공합니다.

리소스 소유자(최종 사용자)

리소스 소유자는 계정 연결을 수행하여 계정과 연결된 리소스에 대한 AWS IoT Device Management 고객 액세스를 위한 관리형 통합을 허용합니다. 예를 들어 최종 사용자가 Lights™ 모바일 애플리케이션에 온보딩한 스마트 전구를 가정해 보겠습니다. 리소스 소유자는 디바이스를 구매하고 온보딩한 최종 사용자 계정을 말합니다. 이 예제에서 리소스 소유자는 Lights OAuthOAuth2.0 계정으로 모델링됩니다. 리소스 소유자로서이 계정은 명령을 실행하고 디바이스를 관리할 수 있는 권한을 제공합니다.

리소스 서버

이는 (디바이스 데이터)에 액세스하기 위해 권한이 필요한 보호된 리소스를 호스팅하는 서버입니다. AWS 고객은 최종 사용자를 대신하여 보호된 리소스에 액세스해야 하며 계정 연결 후 AWS IoT Device Management 커넥터에 대한 관리형 통합을 통해 액세스해야 합니다. 이전의 스마트 전구를 예로 들어보면 리소스 서버는 온보딩된 후 전구를 관리하는 Lights™가 소유한 클라우드 기반 서비스입니다. 리소스 서버를 통해 리소스 소유자는 스마트 전구를 켜고 끄는 등의 명령을 스마트 전구에 실행할 수 있습니다. 보호된 리소스는 최종 사용자의 계정 및 최종 사용자가 권한을 제공했을 수 있는 기타 계정/엔터티에만 권한을 제공합니다.

클라이언트

이 컨텍스트에서 클라이언트는 C2C 커넥터입니다. 클라이언트는 최종 사용자를 대신하여 리소스 서버 내의 리소스에 대한 액세스 권한이 부여된 애플리케이션으로 정의됩니다. 계정 연결 프로세스는 타사 클라우드 내에서 최종 사용자의 리소스에 대한 액세스를 요청하는 커넥터인 클라이언트를 나타냅니다.

커넥터는 OAuth 클라이언트이지만 AWS IoT Device Management의 관리형 통합은 커넥터를 대신하여 작업을 수행합니다. 예를 들어 AWS IoT Device Management의 관리형 통합은 권한 부여 서버에 액세스 토큰을 얻도록 요청합니다. 커넥터는 리소스 서버의 보호된 리소스(디바이스 데이터)에 액세스하는 유일한 구성 요소이므로 여전히 클라이언트로 간주됩니다.

최종 사용자가 온보딩한 스마트 전구를 고려합니다. 고객 플랫폼과 Lights™ 권한 부여 서버 간에 계정 연결이 완료되면 커넥터 자체가 리소스 서버와 통신하여 최종 사용자의 스마트 전구에 대한 정보를 검색합니다. 그러면 커넥터가 최종 사용자로부터 명령을 수신할 수 있습니다. 여기에는 Lights™ 리소스 서버를 통해 조명을 자동으로 켜거나 끄는 작업이 포함됩니다. 따라서 커넥터를 클라이언트로 지정합니다.