[api] REST API 로그인 패턴

Roy T. Fielding과 Richard N. Taylor의 현대 웹 아키텍처의 기본 설계 , 즉 모든 REST 용어의 작업 순서에는 클라이언트-서버 상호 작용에 대한 정의가 포함됩니다.

모든 REST 상호 작용은 상태 비 저장 입니다. 즉, 각 요청에는 선행 요청과 상관없이 커넥터가 요청을 이해하는 데 필요한 모든 정보가 포함됩니다 .

이 제한은 다음과 같은 네 가지 기능을 수행합니다.이 특별한 경우에는 1, 3이 중요합니다

• 1 일 :이 커넥터가 요청 사이의 애플리케이션 상태를 유지하기위한 어떤 필요 제거 하여 물리적 자원의 소비를 줄이고 확장 성을 개선을;
• 셋째 : 중개자가 서비스를 동적으로 재 배열 할 때 필요할 수 있는 요청을 개별적 으로보고 이해할 수 있습니다.

이제 보안 사례로 돌아가겠습니다. 모든 단일 요청에는 모든 필수 정보가 포함되어야하며 권한 부여 / 인증은 예외가 아닙니다. 이것을 달성하는 방법? 요청이있을 때마다 필요한 모든 정보를 유선으로 보내십시오.

이를 보관하는 방법 중 하나는 해시 기반 메시지 인증 코드 또는 HMAC 입니다. 실제로 이것은 모든 요청에 ​​현재 메시지의 해시 코드를 추가하는 것을 의미합니다. 비밀 암호 키 와 함께 암호 해시 기능 으로 계산 된 해시 코드 . 암호화 해시 함수 는 사전 정의되거나 주문형 코드 REST 개념 (예 : JavaScript)의 일부입니다. 비밀 암호화 키 는 서버에서 클라이언트로 리소스로 제공해야하며 클라이언트는이 키를 사용하여 모든 요청에 ​​대한 해시 코드를 계산합니다.

HMAC 구현 에는 많은 예제가 있지만 다음 세 가지에주의를 기울이고 싶습니다.

• Amazon Simple Storage Service (Amazon S3)에 대한 REST 요청 인증
• Quiricetion에 대한 Mauriceless의 답변 : “RESAful WCF API에서 HMAC 인증을 구현하는 방법”
• crypto-js : 표준 및 보안 암호화 알고리즘의 JavaScript 구현

실제로 작동하는 방식

클라이언트가 비밀 키를 알고 있으면 리소스를 사용할 수 있습니다. 그렇지 않으면 임시 키 (상태 코드 307 임시 경로 재 지정)를 사용하여 비밀 키를 승인하고 가져 와서 원래 자원으로 다시 경로 재 지정합니다. 이 경우 클라이언트에게 권한을 부여 할 URL이 무엇인지 미리 알 필요 가 없으며 시간에 따라이 스키마를 조정할 수 있습니다.

이것이 올바른 해결책을 찾는 데 도움이되기를 바랍니다.

---

답변