[rest] RESTful 인증

RESTful 클라이언트-서버 아키텍처에서 인증을 처리하는 방법은 논쟁의 여지가 있습니다.

일반적으로 SOA over HTTP 세계에서 다음을 통해 달성 할 수 있습니다.

• HTTPS를 통한 HTTP 기본 인증;
• 쿠키 및 세션 관리;
• HTTP 헤더의 토큰 (예 : OAuth 2.0 + JWT);
• 추가 서명 매개 변수를 사용한 쿼리 인증

소프트웨어 아키텍처를 최상으로 맞추려면 이러한 기술을 조정하거나 더 잘 혼합해야합니다.

각 인증 체계에는 보안 정책 및 소프트웨어 아키텍처의 목적에 따라 고유 한 PRO 및 CON이 있습니다.

HTTPS를 통한 HTTP 기본 인증

표준 HTTPS 프로토콜을 기반으로하는이 첫 번째 솔루션은 대부분의 웹 서비스에서 사용됩니다.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

모든 브라우저에서 기본적으로 사용할 수 있지만 구현하기 쉽지만 브라우저에 표시되는 끔찍한 인증 창과 같이 알려진 몇 가지 단점이 있습니다. 그리고 사용자 이름과 비밀번호가 (HTTPS를 통해) 서버로 전송된다는 사실 (키보드 입력 중 클라이언트 측에만 비밀번호를 유지하고 서버에 보안 해시로 저장되도록 더 안전해야 함) .

다이제스트 인증을 사용할 수도 있지만 MiM 또는 재생 공격에 취약 하고 HTTP에만 해당 되므로 HTTPS도 필요합니다 .

쿠키를 통한 세션

솔직히 말해서 서버에서 관리되는 세션은 실제로 Stateless가 아닙니다.

쿠키 콘텐츠 내에서 모든 데이터를 유지 관리하는 것이 가능할 수 있습니다. 그리고 쿠키는 의도적으로 서버 측에서 처리됩니다 (실제로 클라이언트는이 쿠키 데이터를 해석하려고 시도하지 않습니다. 각 요청마다 서버에 다시 전달합니다). 그러나이 쿠키 데이터는 응용 프로그램 상태 데이터이므로 클라이언트는 순수한 Stateless 환경에서 서버가 아니라 관리해야합니다.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

쿠키 기술 자체는 HTTP 연결이므로 프로토콜에 독립적 인 IMHO이어야하는 RESTful이 아닙니다. MiM 또는 Replay 공격에 취약합니다 .

토큰을 통해 부여 (OAuth2)

대안은 요청이 인증되도록 HTTP 헤더 내에 토큰을 넣는 것입니다. 이것은 무엇 의 OAuth 2.0 예를 들어, 않습니다. RFC 6749를 참조하십시오 .

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

간단히 말해서 쿠키와 매우 유사하며 동일한 문제가 발생합니다. 상태 비 저장, HTTP 전송 세부 정보에 의존하지 않으며 MiM 및 재생을 비롯한 많은 보안 취약점 이 HTTPS를 통해서만 사용되어야합니다. 일반적으로 JWT 는 토큰으로 사용됩니다.

쿼리 인증

쿼리 인증은 URI의 일부 추가 매개 변수를 통해 각 RESTful 요청에 서명하는 것으로 구성됩니다. 참조 이 참조 문서를 .

이 기사에서는 다음과 같이 정의되었습니다.

개인 자격 증명을 서명 토큰으로 사용하여 알파벳 순서로 소문자로 정렬 된 쿼리 매개 변수에 서명하여 모든 REST 쿼리를 인증해야합니다. 쿼리 문자열을 URL 인코딩하기 전에 서명이 이루어져야합니다.

이 기술은 Stateless 아키텍처와 더 호환 될 수 있으며 간단한 세션 관리 (DB 지속성 대신 메모리 내 세션 사용)로 구현할 수도 있습니다.

예를 들어, 다음은 위 링크의 일반적인 URI 샘플입니다.

GET /object?apiKey=Qwerty2010

다음과 같이 전송되어야합니다.

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

서명되는 문자열은 /object?apikey=Qwerty2010&timestamp=1261496500이고 서명은 API 키의 개인 구성 요소를 사용하여 해당 문자열의 SHA256 해시입니다.

서버 측 데이터 캐싱을 항상 사용할 수 있습니다. 예를 들어, 프레임 워크에서 URI 레벨이 아닌 SQL 레벨에서 응답을 캐시합니다. 따라서이 추가 매개 변수를 추가해도 캐시 메커니즘이 손상되지 않습니다.

JSON 및 REST를 기반으로하는 클라이언트 서버 ORM / SOA / MVC 프레임 워크의 RESTful 인증에 대한 세부 사항은 이 기사 를 참조하십시오 . HTTP / 1.1을 통한 통신뿐만 아니라 명명 된 파이프 또는 GDI 메시지 (로컬로)를 통한 통신을 허용하기 때문에 진정으로 RESTful 인증 패턴을 구현하려고 시도했지만 HTTP 고유성 (헤더 또는 쿠키 등)에 의존하지 않았습니다.

나중에 참고 : URI에 서명을 추가하는 것은 나쁜 습관으로 보일 수 있습니다 (예를 들어 http 서버 로그에 표시되기 때문에) 예를 들어 재생을 피하기 위해 적절한 TTL에 의해 완화되어야합니다. 그러나 http 로그가 손상되면 보안 문제가 더 커질 것입니다.

실제로, 다가오는 OAuth 2.0 용 MAC 토큰 인증 은 “Granted by Token”현재 체계와 관련하여 크게 개선 될 수 있습니다. 그러나 이것은 여전히 ​​진행중인 작업이며 HTTP 전송과 관련이 있습니다.

결론

REST는 실제로 HTTP 기반 일뿐 아니라 실제로 HTTP를 통해 구현되는 경우에도 결론을 내릴 가치가 있습니다. REST는 다른 통신 계층을 사용할 수 있습니다. 따라서 RESTful 인증은 Google이 응답하는 모든 HTTP 인증의 동의어가 아닙니다. HTTP 메커니즘을 전혀 사용해서는 안되지만 통신 계층에서 추상화해야합니다. 그리고 HTTP 통신을 사용하는 경우 Let ‘s Encrypt 이니셔티브 덕분에 인증 체계 외에 필요한 적절한 HTTPS를 사용하지 않을 이유가 없습니다.

---

답변