보안 RESTful 웹 서비스 를 구현해야 합니다 . 이미 Google을 사용하여 조사를했지만 막혔습니다.
옵션 :
TLS (HTTPS) +
고려할 수있는 더 많은 옵션이 있습니까? OAuth이면 어떤 버전입니까? 그것이 중요합니까? 지금까지 읽은 OAuth 2.0 with Bearer Token (즉, 서명 없음)은 안전하지 않은 것 같습니다 .
REST 기반 인증 에 대한 또 다른 흥미로운 기사를 발견했습니다 .
답변:
또 다른 매우 안전한 방법이 있습니다. 클라이언트 인증서입니다. https에서 서버에 연결할 때 서버가 SSL 인증서를 표시하는 방법을 알고 있습니까? Well 서버는 클라이언트로부터 인증서를 요청할 수 있으므로 클라이언트가 자신이 말하는 사람임을 알 수 있습니다. 클라이언트는 인증서를 생성하고 보안 채널을 통해 인증서를 제공합니다 (예 : USB 키를 사용하여 사무실에 들어오는 경우-바람직하게는 트로이 목마되지 않은 USB 키).
인증서 클라이언트 인증서 (필요한 경우 서명자의 인증서) 의 공개 키를 웹 서버에로드하면 웹 서버는 인증서에 해당하는 개인 키를 가진 사람을 제외한 누구의 연결도 허용하지 않습니다. 알고 있습니다. HTTPS 계층에서 실행되므로 OAuth와 같은 애플리케이션 수준 인증을 완전히 건너 뛸 수도 있습니다 (요구 사항에 따라 다름). 계층을 추상화하고 로컬 인증 기관을 만들고 클라이언트의 인증서 요청에 서명하여 '사무실로 가져 오기'및 '서버에 인증서로드'단계를 건너 뛸 수 있습니다.
목에 통증이 있습니까? 물론. 모든 것에 좋은가요? 아니. 매우 안전합니까? 예.
그러나 인증서를 안전하게 유지하는 클라이언트에 의존합니다 (개인 키를 온라인에 게시 할 수 없음). 일반적으로 다른 사람이 등록하고 연결하는 대신 클라이언트에게 서비스를 판매 할 때 사용됩니다.
어쨌든, 그것은 당신이 찾고있는 해결책이 아닐 수도 있지만 (정직하지 않을 것입니다), 그것은 또 다른 선택입니다.
HTTP Basic + HTTPS는 일반적인 방법 중 하나입니다.
OAuth 버전 중에서 선택하는 경우 OAuth 2.0을 사용하세요.
OAuth 전달자 토큰은 보안 전송에만 사용해야합니다.
OAuth 전달자 토큰은 대화를 암호화하는 전송만큼만 안전하거나 안전하지 않습니다. HTTPS는 리플레이 공격으로부터 보호하므로 베어러 토큰이 리플레이로부터 보호 할 필요가 없습니다.
누군가가 귀하의 Bearer 토큰을 가로 채면 API를 호출 할 때 귀하를 가장 할 수 있다는 것은 사실이지만 이러한 위험을 완화 할 수있는 방법은 많습니다. 토큰에 긴 만료 기간을 제공하고 클라이언트가 토큰을 로컬에 저장하기를 기대하는 경우 토큰에 짧은 만료 시간을 제공하고 클라이언트가 모든 세션에 대해 새 토큰을 획득하도록 요구하는 것보다 토큰이 가로 채서 오용 될 위험이 더 큽니다. 그리고 클라이언트에게 토큰을 유지하지 말라고 조언합니다.
여러 참가자를 통과하는 페이로드를 보호해야하는 경우 HTTPS / SSL은 그래프의 하나의 링크 만 암호화하므로 HTTPS / SSL 이상의 것이 필요합니다. 이것은 OAuth의 결함이 아닙니다.
Bearer 토큰은 클라이언트가 쉽게 구할 수 있고 클라이언트가 API 호출에 사용하기 쉬우 며 Google, Facebook 및 기타 여러 서비스의 공개 API를 보호하기 위해 널리 사용됩니다 (HTTPS와 함께).