Jamstack의 API 및 인증

Jamstack 아키텍처의 핵심은 정적 웹 사이트에 강력한 동적 기능을 제공하는 "API"(Application Program Interface)에 있습니다. API를 통해 개발자는 복잡성을 전환하고 정적 웹 사이트에 동적 기능을 추가 할 수 있습니다. API에 액세스하려면 일반적으로 AUT (Authentication) 형태로 제공되는 요청의 진위를 확인해야하며 사용중인 서비스 및 완료 작업에 따라 클라이언트 또는 서버 측에서 수행 할 수 있습니다.

다양한 프로토콜의 차이로 인해 API의 인증 구현이 다릅니다. 이러한 인증 프로토콜 및 구현 세부 사항은 API를 Jamstack 사이트에 통합 할 때 추가 문제를 추가합니다. 다행히도, 이것은 순서 부족하지 않습니다. 각 프로토콜은 특정 사용 사례에 매핑 될 수 있으며 인증 구현의 핵심은이를 이해하는 것입니다.

이를 더 잘 설명하기 위해 다양한 프로토콜과 가장 적합한 시나리오를 살펴 보겠습니다.

계약 개요

OAUTH 2.0은 오늘 인증이 따르는 일반적인 표준입니다. OAUTH는 클라이언트와 API 엔드 포인트 간의 관계를 정의하는 일련의 승인을 포함하는 다소 유연한 승인 프레임 워크입니다. OAUTH 프로세스에서 클라이언트 응용 프로그램은 승인 된 엔드 포인트에서 액세스 토큰을 요청하고 해당 토큰을 사용하여 API 엔드 포인트에 대한 요청에 서명합니다.

승인 코드, 암시 적 프로세스, 리소스 소유자 비밀번호 및 클라이언트 자격 증명의 네 가지 주요 유형이 있습니다. 우리는 각각을 별도로 공부할 것입니다.

승인 코드 승인

모든 OAUTH 승인 유형 중에서, 승인 코드 승인이 가장 일반적 일 것입니다. 이 승인 프로세스는 주로 사용자가 명시 적으로 권한을 부여한 후 API 요청을 승인하기위한 액세스 토큰을 얻는 데 사용됩니다. 2 단계 프로세스를 따릅니다.

• 먼저, 사용자는 동의 화면 (즉, 권한 부여 서버)으로 지정되며, 여기서 개인 계정 및 데이터에 액세스 할 수있는 서비스 권한을 부여합니다.
• 허가가 얻어지면 다음 단계는 인증 서버에서 액세스 토큰을 검색 한 다음 API 엔드 포인트의 요청을 인증하는 데 사용할 수 있습니다.

인증 코드 인증은 다른 승인 유형에 비해 사용자에게 명시 적 승인을 요청하는 단계를 추가하여 추가 보안 계층을 추가합니다. 이 다중 단계 코드 교환은 액세스 토큰이 노출되지 않으며 응용 프로그램과 인증 서버 간의 안전한 백엔드 채널을 통해 항상 전송됩니다. 이런 식으로 공격자는 요청을 가로 질러 액세스 토큰을 쉽게 훔칠 수 없습니다. Gmail 및 Google Calendar와 같은 Google 소유 서비스는이 권한 부여 코드 프로세스를 사용하여 사용자 계정의 개인 콘텐츠에 액세스합니다. 이 워크 플로에 대해 자세히 알아 보려면이 블로그 게시물을 확인하여 자세한 내용을 확인하십시오.

암시 적 승인

암시 적 승인은 승인 코드 승인과 유사하지만 하나의 명백한 차이점은 다음과 같습니다. 사용자가 승인 코드를 검색 한 다음 액세스 토큰으로 바꾸는 권한을 부여하는 대신 URL의 스 니펫 (해시) 부분을 리디렉션하여 즉시 액세스 토큰을 반환합니다 (즉, 프론트 채널) .

인증 코드 단계가 줄어들기 때문에 암시 적 승인 프로세스는 토큰 노출의 위험이 있습니다. 토큰은 URL에 직접 내장되어 브라우저 기록에 기록되어 있으므로 리디렉션이 인터셉트되면 쉽게 액세스 할 수 있습니다.

취약점에도 불구하고 암시 적 승인은 단일 페이지 응용 프로그램과 같은 사용자 에이전트 기반 클라이언트에 유용합니다. 클라이언트 측 렌더링 된 응용 프로그램에서 응용 프로그램 코드 및 스토리지에 쉽게 액세스 할 수 있으므로 클라이언트 키를 보호 할 수있는 안전한 방법이 없습니다. 암시 적 흐름은 클라이언트의 사용자를 빠르고 쉬운 방법으로 응용 프로그램에 제공 함으로써이 문제에 대한 논리적 솔루션이됩니다. 또한 CORS 문제를 해결하는 효과적인 방법입니다. 특히 도메인 크로스 도메인 요청을 지원하지 않는 타사 공인 서버를 사용할 때는 효과적인 방법입니다. 이 접근법의 고유 한 토큰 노출 위험으로 인해 암시 적 프로세스의 액세스 토큰은 종종 일시적이며 새로 고침 토큰을 발행하지 않는다는 점에 유의해야합니다. 따라서이 프로세스는 각 요청에 대해 권한있는 리소스에 로그인해야 할 수 있습니다.

자원 소유자 비밀번호 인증

리소스 소유자 비밀번호 인증의 경우 리소스 소유자는 사용자 이름 및 비밀번호 자격 증명을 인증 서버로 보낸 다음 선택적인 새로 고침 토큰으로 액세스 토큰을 다시 보냅니다. 리소스 소유자 자격 증명은 클라이언트 응용 프로그램과 인증 서버 간의 인증 교환에서 볼 수 있으므로 자원 소유자와 클라이언트 응용 프로그램간에 신뢰 관계가 있어야합니다. 분명히 다른 권한 부여 유형만큼 안전하지는 않지만 리소스 소유자 비밀번호 인증은 자사 고객에게 우수한 사용자 경험을 제공합니다. 이 승인 프로세스는 응용 프로그램이 특권이 높거나 장치 운영 체제에서 작업하는 상황에 가장 적합합니다. 이 승인 프로세스는 일반적으로 다른 프로세스가 가능하지 않은 경우 사용됩니다.

클라이언트 자격 증명 인증

클라이언트 자격 증명 인증 유형은 주로 클라이언트가 사용자 컨텍스트 외부에서 액세스 토큰을 얻어야 할 때 사용됩니다. 이는 보호 된 리소스에 대한 모든 액세스에 사용자의 명시 적 허가가 부여되도록 보장되지 않을 때 기계 간 인증에 적용됩니다. 백엔드에서 실행되는 CLI 및 서비스는이 권한 부여 유형이 유용한 경우입니다. 사용자 로그인에 의존하는 대신 클라이언트 ID와 키를 전달하여 토큰을 얻은 다음 API 요청을 인증하는 데 사용할 수 있습니다.

일반적으로 클라이언트 자격 증명 인증에서 응용 프로그램이 실행되고 API 호출을 통해 서비스 계정이 작성됩니다. 이런 식으로 사용자는 직접 관여하지 않으며 응용 프로그램은 여전히 ​​요청을 계속 인증 할 수 있습니다. 이 워크 플로우는 응용 프로그램이 특정 사용자 데이터가 아닌 자체 데이터 (예 : 분석과 같은)에 액세스하려는 경우 매우 일반적입니다.

결론적으로

Jamstack 사이트는 타사 서비스에 의존하여 복잡한 기능을 구현하므로 보안을 유지하는 데 신중하게 인증 솔루션을 설계하는 것이 필수적입니다. Jamstack에서 데이터를 교환하는 주요 방법으로 API는 그 중 일부입니다. 우리는 각각 고유 한 장점과 사용자 경험에 영향을 미치는 4 가지 API 요청 인증 방법을 살펴 보았습니다.

우리는 처음 에이 네 가지가 API의 데이터를 요청하는 데 사용되는 주요 인증 형태라고 언급했습니다. Oauth.net에서 매우 좋은 개요 인 기타 유형이 많이 있습니다. 전체적으로 웹 사이트는 사용 가능한 인증 유형뿐만 아니라 전체 OAUTH 프레임 워크로도 탐구되었습니다.

다른 방법보다 하나의 방법을 선호합니까? 지적 할 수있는 사용 예제가 있습니까? 의견을 공유하십시오!

위 내용은 Jamstack의 API 및 인증의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!