RESTful 방식으로 웹페이지 사용자를 인증하는 데 선호되는 방법은 무엇입니까?

https://stackoverflow.com/questions/2010699

18-09-2019
|

문제

저는 새로운 실험적인 웹 애플리케이션 프레임워크를 개발 중이며 RESTful에 관심을 기울이기로 결정했습니다.기본 사항을 읽었으며 RESTful이라는 개념을 꽤 잘 이해하고 있는 것 같습니다.

저는 URL을 사용하여 시스템에서 '명사'를 엄격하게 정의하고 HTTP 요청 메서드에서 '동사'를 가져오는 시스템을 실행하고 있습니다.나는 HTML 양식이 제공할 수 없는 DELETE 및 PUT 메소드에 대한 액세스를 제공하기 위해 javascript ajax 호출을 사용하고 있습니다.(이러한 조치가 RESTful이 되기 위해 엄격하게 요구되는 것은 아니지만 'Uniform Interface' 요구 사항을 충족한다는 것을 알고 있습니다.)

문제는 인증의 무상태 및 캐시 가능성과 관련됩니다.웹 사이트의 사용자 인증을 위한 표준 모델에는 "로그인" 인증 이벤트가 포함되며, 그 후(성공한 경우) 사용자는 지속적인 보안 세션을 통해 "벽 내부"에 있게 되며 인증되지 않은 사용자는 볼 수 없는 후속 요청에 대한 작업을 보고 수행할 수 있습니다.이러한 인증 지속성은 RESTful-ness를 손상시키는 것으로 보입니다.캐싱 및 상태 비저장은 인증된 사용자가 동일한 요청에 대해 인증되지 않은 사용자에게 표시되는 HTML과 다른 HTML을 볼 수 있기 때문에 손상된 것으로 보입니다(예를 들어 로그인된 요청에 대한 사이드바에 로그인 양식이 있을 수 있음). 아웃 사용자).

인증이 필요한 요청에서만 사용자를 인증하기 위해 www-authenticate 전략을 사용하는 것은 지속적인 보안 세션 개념을 포함하지 않기 때문에 올바른 방향으로 나아가는 단계인 것 같습니다.그러나 우리 모두가 웹사이트에서 기대하는 것과 일치하도록 최종 사용자에게 "로그인된" 모습을 어떻게 묘사할 것인지에 대한 의문이 여전히 남아 있습니다.

그렇다면 현재의 생각으로는 HTML에서 로그인된 장식을 허용하면서 엄격한 RESTful 방식으로 웹페이지의 인증 및 권한 부여를 처리하는 데 선호되는 방법은 무엇입니까?

해결책

이러한 인증의 지속성은 편안함을 깨는 것 같습니다

사용자를 인증하는 대신 세션 작성에 대해 생각할 수 있습니다. 적절한 HTTP 상태 코드 (200 : OK, 403 : Forbidden 등)와 함께 새 "세션 ID"가 반환됩니다.

사용자는 아마도 인증되지 않은 사용자가 동일한 요청에 대해 볼 수있는 HTML과 다른 HTML을 보게 될 것입니다.

당신은 당신의 REST 서버를 물을 것입니다 : "이 세션 ID에 대한 HTML (또는 모든 리소스)을 얻을 수 있습니까?" HTML은 "세션 ID"에 따라 다릅니다.

이 방법을 사용하면 "지속적인 보안 세션"을위한 벽이 없습니다. 당신은 단순히 세션에서 행동하고 있습니다.

이 방법을 선택하면 명사 (또는 리소스)는 실제 세션을 나타냅니다.

다른 팁

"웹 사이트에서 사용자 인증을위한 표준 모델에는"로그인 "인증 이벤트가 포함되며, 그 후 (성공한 경우) 사용자는"지속적인 보안 세션으로 "벽 안에 있습니다".

이것은 실제로 맞지 않습니다. 그것은 부분적으로 사실이지만 자신의 인증을 발명하는 웹 사이트에만 해당됩니다.
"Digest Authentication"을 사용하는 경우 브라우저는 각 요청에 따라 자격 증명을 보내야합니다.

Digest 인증 (각 요청마다 자격 증명)은 완전히 편안합니다.

그렇게.

물건을 약간 더 간소화하려면 시간을 기준으로 Digest 인증을 계산하여 일정 기간 동안 (6 분, 0.1 시간이 좋습니다). 모든 사람이 몇 분 동안 요청하면 401 상태를 보내고 다이제스트의 재 계산이 필요합니다.

사용자 별 요소가있는 페이지에 대해 중개자의 캐시 가능성을 보존하는 한 가지 옵션은 AJAX를 통해 사용자 별 마크 업을 추가하는 것입니다. 사용자 로그인을 기반으로 다른 것을 반환하는 리소스에 XHR 요청을 수행하는 일부 JavaScript를 포함하여 동일한 페이지를 모두 사용합니다. 그런 다음 이것을 클라이언트 측의 페이지로 병합합니다. 그런 다음 페이지의 주요 부분은 모든 사용자에게 동일하므로 캐시 가능합니다.

또 다른 옵션은 ESI를 사용하는 것입니다 (Edge Side 포함). 이를 통해 캐시 자체는 다른 표현을 병합하여 최종 결과를 구축 할 수 있습니다.

사용자 인증의 "명사"는 세션입니다. 따라서 로그인 양식은 게시물 요청을 사용하여 새 세션을 "작성"하고 로그 아웃은 삭제 요청을 사용하여 세션을 "삭제"합니다.

나는 당신이 휴식에 반대하는 인증의 지속성에 대해 의미하는 바를 알고 있지만, 쿠키 (지속성의 환상을주는)는 단순히 각 요청의 일부입니다.

"이러한 인증 지속성은 RESTful-ness를 깨뜨리는 것 같습니다.인증된 사용자는 동일한 요청에 대해 인증되지 않은 사용자가 보는 HTML과 다른 HTML을 보게 되므로 캐싱 및 상태 비저장이 손상된 것으로 보입니다."

인증 정보에 따라 리소스 표현이 조금씩 달라도 괜찮습니다.인증 정보는 메시지의 일부이므로 메시지는 여전히 "자체 설명"입니다.개념적으로는 여전히 동일한 리소스에 액세스하고 있으며 편집 및 삭제 링크는 추가 데이터 조각이 아닌 전환이 허용됩니다.리소스에 액세스하는 사람에 따라 사용 가능한 전환을 제어하는 것이 유효한 것 같습니다.

Re : Daniel의 답변 :

세션이 빠르게 삭제되는 과도 객체 인 경우, 이는 캐시가 가능하지 않습니다. 생성 한 캐시는 하루의 유용한 수명 만 가지만 캐시에 공간을 계속 사용하기 때문에 캐시 가능하지 않습니다.

사용자를 객체로 만들고 Digest 인증 (또는 쿠키)을 사용하여 인증하는 것이 더 낫지 않습니까? 이렇게하면 각 사용자는 하루 종일 캐시 대신 자신의 지속적인 캐시를 받고 사라집니다.

이것은 또한 사용자에 따라 페이지를 다르게 보이게하기 때문에 ( 'Hello [name] 등을 추가)와 "로그인"과 "로그인 된"상태의 차이는 의존하기 때문에 나에게 더 논리적으로 의미가 있습니다. 사용자가 URL에 포함되어 있는지 여부. 특정 사람이 해당 사용자 특정 URL에 대한 액세스 권한이 부여되는지 여부는 해당 사용자로 인증 할 수 있는지 여부에 따라 다릅니다.

RESTful 프레임워크를 웹 애플리케이션에서만 사용하고 제3자를 위한 API로 사용하지 않을 경우 애플리케이션의 나머지 부분과 동일한 인증 체계를 사용할 수 없는 이유가 없습니다.이 인증을 "애플리케이션" 수준보다 낮은 수준의 계층으로 생각할 수 있습니다.애플리케이션 수준은 순수한 RESTful 방식으로 여전히 상태 비저장 상태로 유지될 수 있습니다.

물론 RESTful 웹 API를 만들 계획이라면 이에 대해 좀 더 생각해 볼 필요가 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow