웹을 통해 REST API를 보호 할 수있는 방법을 찾고 있는데, Amazon's Non-SSL & Non-OAuth way과 현재 HTTPS + OAuth 2 방식 중 하나를 선택하고 있습니다. 내가 뭔가를 놓치고 있는지).OAuth 소비자 키 대 앱 키
아직 OAuth 2 흐름을 이해하지 못했습니다. 공개 키와 비공개 키가있는 경우이 키는 응용 프로그램 만 인증합니다. 응용 프로그램 사용자는 어떻습니까? 응용 프로그램의 각 사용자를 나타내는 하위 공용/개인 키가 있습니까?
예를 들어, "응용 프로그램"이 "회사 앱"인 경우와 외부에서 개발 된 응용 프로그램이 아닌 경우는 어떻게됩니까? 공개 키와 개인 키 중 하나가 수천 명의 사용자를 구분하는 방법은 무엇입니까?
"다중 사용자 OAuth"입니까?
아마존의 솔루션에 익숙하지 않지만 단순한 요청 서명을 사용하고있는 것으로 보입니다. 반대로 OAuth2는보다 정교합니다. 여러 시나리오를 지원하며, "인증 코드 부여"및 "암시 적 부여"플로우가 가장 일반적으로 사용됩니다. 아래 설명은 두 시나리오에 모두 적용됩니다.
OAuth2에서 서비스는 실제로 사용자 자격 증명에 대해 아무 것도 모릅니다. 따라서 사용자에게는 "하위 키"와 같은 것이 없습니다. 서비스가 승인을 요청하면 사용자의 브라우저가 OAuth 승인 서버로 리디렉션됩니다. 일부 마법은 내부적으로 발생합니다 (클라이언트 응용 프로그램의 경우 블랙 박스입니다) : 사용자가 필요한 경우 인증하고 요청을 승인할지 여부를 결정합니다. 그런 다음 브라우저는 인증 결과와 함께 클라이언트 응용 프로그램으로 재 지정됩니다. 따라서 클라이언트 응용 프로그램이 사용자 자격 증명에 대해 아는 것은 불가능하지만 전혀 필요하지 않습니다. 대신, 사용자의 보호 된 자원에 액세스 할 수있는 토큰 만 수신합니다. 토큰은 기본적으로 특정 작업에 대한 일회 승인입니다.