TsgcHTTP_OAuth2_Client

클라이언트가 새 Access Token이 필요할 때, Authorization 서버로부터의 응답을 처리하기 위해 자동으로 HTTP 서버를 시작합니다.

소개

이 구성 요소는 클라이언트와 다른 역할 간의 흐름을 처리할 수 있게 합니다. 기본적으로 Active := True로 설정하면 새 웹 브라우저를 열고 사용자에게 권한 부여를 요청합니다. 성공하면 권한 부여 서버가 애플리케이션에 토큰을 전송하고, 이 토큰이 처리되며, 이 토큰으로 클라이언트가 리소스 서버에 연결할 수 있습니다. 이 구성 요소는 권한 부여 서버 응답을 처리하는 간단한 HTTP 서버를 시작하고 HTTP 클라이언트를 사용하여 Access Token을 요청합니다.

 

GrantType

 

클라이언트는 다음 유형의 권한 부여를 지원합니다:

 

auth2Code: 단일 페이지 애플리케이션, 웹 애플리케이션, 네이티브 설치 애플리케이션을 포함한 대부분의 애플리케이션 유형에서 인증 및 권한 부여를 수행하는 데 사용됩니다. 이 흐름을 통해 앱은 보안 리소스에 액세스하는 데 사용할 수 있는 access_token, 추가 access_token을 얻기 위한 갱신 토큰, 그리고 로그인한 사용자의 ID 토큰을 안전하게 획득할 수 있습니다.

 

 

auth2CodePKCE: PKCE가 활성화된 auth2Code와 동일한 인증 플로입니다. PKCE(Proof Key for Code Exchange)는 OAuth 2.0의 보안 확장으로, 네이티브 및 단일 페이지 애플리케이션의 권한 부여 플로 보안을 강화하도록 설계되었습니다. 특히 권한 부여 코드가 전송 중에 가로채기에 노출될 수 있는 공개 클라이언트에서 가로채기 공격의 위험을 완화합니다. 일반적으로 이 옵션은 네이티브 및 모바일 앱에서 사용됩니다.

 

auth2ClientCredentials: 이 유형의 grant는 사용자와의 즉각적인 상호 작용 없이 백그라운드에서 실행되어야 하는 서버 간 상호 작용에 일반적으로 사용됩니다. 이러한 유형의 애플리케이션은 종종 데몬 또는 서비스 계정이라고 합니다.

 

 

auth2DeviceCode: 브라우저가 없거나 입력 기능이 제한된 스마트 TV, 미디어 콘솔, IoT 장치와 같은 입력 제약 장치를 위한 Device Authorization Grant(RFC 8628)입니다. 장치는 사용자 코드와 확인 URI를 표시합니다. 사용자는 보조 장치(휴대폰 또는 컴퓨터)에서 URI를 방문하고 코드를 입력하여 권한을 부여합니다.

 

LocalServerOptions

 

클라이언트가 새 Access Token이 필요할 때, Authorization 서버로부터 응답을 처리하기 위해 자동으로 HTTP 서버를 시작합니다. 이 서버는 사용자에게 투명하며 일반적으로 localhost에서 작동합니다. 기본적으로 포트 8080을 사용하지만 필요한 경우 변경할 수 있습니다.

 

 

AuthorizationServerOptions

 

여기서 Authorization과 Access Token의 URL을 설정해야 합니다. 일반적으로 이것들은 API 사양에 제공됩니다. Scope는 클라이언트가 요청한 모든 범위의 목록입니다. 예:

 

 

OAuth2Options

 

ClientId는 서버에 클라이언트의 식별 정보를 알리는 필수 필드입니다. ClientId를 얻는 방법을 알려면 API 사양을 확인하십시오. client secret도 마찬가지입니다.

때때로 서버는 Basic Authentication을 사용하여 연결하기 위해 사용자와 비밀번호를 요구합니다. 이 경우 Username/Password 필드에서 이를 설정할 수 있습니다. 예제:

 

 

HTTPClientOptions

 

여기서 새 토큰을 요청하기 위해 HTTP Server에 연결할 때 클라이언트 옵션을 사용자 지정할 수 있습니다.

 

TLSOptions: TLS가 활성화된 경우, 여기에서 일부 TLS 속성을 사용자 정의할 수 있습니다.

 

ALPNProtocols: 서버로 전송될 ALPN 프로토콜 목록입니다.

RootCertFile: 루트 인증서 파일의 경로입니다.

CertFile: 인증서 파일 경로입니다.

KeyFile: 인증서 키 파일의 경로입니다.

Password: 인증서가 비밀번호로 보호된 경우 여기에 설정하십시오.

VerifyCertificate: 인증서를 검증해야 하는 경우 이 속성을 활성화하십시오.

VerifyDepth: X.509 인증서에 대해 검증이 수행될 때 허용되는 최대 링크 수를 나타내는 Integer 속성입니다.

Version: 기본적으로 TLS 1.0을 사용하며, 서버가 더 높은 TLS 버전을 요구하는 경우 여기에서 선택할 수 있습니다.

IOHandler: TLS를 사용하여 연결할 때 사용할 라이브러리를 선택합니다.

iohOpenSSL: OpenSSL 라이브러리를 사용하며 Indy 구성 요소의 기본값입니다. win32/win64용 openssl 라이브러리를 배포해야 합니다.

iohSChannel: Microsoft가 Windows용으로 구현한 보안 프로토콜인 Secure Channel을 사용하며, openssl 라이브러리를 배포할 필요가 없습니다. Windows 32/64비트에서만 작동합니다.

OpenSSL_Options: 사용할 OpenSSL API를 정의할 수 있습니다.

APIVersion: 어떤 OpenSSL API를 사용할지 정의할 수 있게 합니다.

oslAPI_1_0: API 1.0 OpenSSL을 사용하며, Indy가 지원하는 최신 버전입니다

oslAPI_1_1: API 1.1 OpenSSL을 사용하며, 당사의 사용자 정의 Indy 라이브러리가 필요하고 OpenSSL 1.1.1 라이브러리(TLS 1.3 지원 포함)를 사용할 수 있게 합니다.

oslAPI_3_0: API 3.0 OpenSSL을 사용하며, 사용자 지정 Indy 라이브러리가 필요하고 OpenSSL 3.0.0 라이브러리(TLS 1.3 지원 포함)를 사용할 수 있습니다.

LibPath: 여기에서 openSSL 라이브러리가 위치한 곳을 구성할 수 있습니다.

oslpNone: 이것이 기본값이며, openSSL 라이브러리는 바이너리가 있는 동일한 폴더 또는 알려진 경로에 있어야 합니다.

oslpDefaultFolder: 모든 IDE 퍼스낼리티에 대해 라이브러리가 위치해야 하는 openSSL 경로를 자동으로 설정합니다.

oslpCustomFolder: 이 옵션이 선택된 경우, LibPathCustom 속성에 전체 경로를 정의하십시오.

LibPathCustom: LibPath = oslpCustomFolder일 때 openSSL 라이브러리가 있는 전체 경로를 여기에 정의하십시오.

UnixSymLinks: Unix 시스템에서 SymLinks 로딩을 활성화하거나 비활성화합니다(기본적으로 활성화되어 있으며, OSX64에서는 예외):

oslsSymLinksDefault: 기본적으로 활성화되지만 OSX64에서는 예외입니다(MacOS Monterey 이후 버전 없이 라이브러리를 로드하려고 하면 실패함).

oslsSymLinksLoadFirst: 버전 라이브러리를 로드하기 전에 SymLink를 로드하고 먼저 시도합니다.

oslsSymLinksLoad: 버전 라이브러리를 로드하려고 시도한 후 SymLinks를 로드합니다.

oslsSymLinksDontLoad: SymLinks를 로드하지 않습니다.

SChannel_Options: Windows Certificate Store의 인증서를 사용할 수 있게 합니다.

CertHash: 는 인증서 Hash입니다. powershell에서 dir 명령을 실행하여 인증서 Hash를 찾을 수 있습니다.

CertStoreName: 인증서가 저장된 스토어 이름. 아래 중 하나를 선택하십시오:

scsnMY(기본값)

scsnCA

scsnRoot

scsnTrust

CertStorePath: 인증서가 저장된 저장소 경로입니다. 아래에서 하나를 선택하십시오:

scspStoreCurrentUser (기본값)

scspStoreLocalMachine

 

LogOptions: 파일 이름이 설정되면 HTTP 클라이언트의 HTTP 요청/응답 로그를 저장합니다.

 

참조