세션이 실제로 RESTfulness를 위반합니까?

RESTful API에서 세션을 사용하는 것이 실제로 RESTfulness를 위반합니까? 나는 많은 의견이 어느 방향으로 가고 있는지 보았지만 세션이 RESTless 라고 확신하지는 않습니다 . 내 관점에서:

• RESTfulness에 대한 인증은 금지되지 않습니다 (그렇지 않으면 RESTful 서비스에 거의 사용되지 않음)
• 인증은 일반적으로 헤더에 요청에 인증 토큰을 보내서 수행됩니다.
• 이 인증 토큰은 어떻게 든 얻어야하고 취소 될 수 있으며이 경우 갱신해야합니다.
• 인증 토큰은 서버에서 검증해야합니다 (그렇지 않으면 인증이 아님).

세션이이를 어떻게 위반합니까?

• 클라이언트 측 세션은 쿠키를 사용하여 실현됩니다
• 쿠키는 단순히 추가 HTTP 헤더입니다
• 세션 쿠키는 언제든지 얻어서 철회 할 수 있습니다
• 세션 쿠키는 필요한 경우 무한 수명을 가질 수 있습니다
• 세션 ID (인증 토큰)는 서버 측에서 검증됩니다.

따라서 클라이언트에게 세션 쿠키는 다른 독점 헤더 Cookie대신 헤더를 사용한다는 점을 제외하고 다른 HTTP 헤더 기반 인증 메커니즘과 정확히 동일 Authorization합니다. 쿠키 값 서버 측에 연결된 세션이 없다면 왜 차이가 있습니까? 서버가 RESTful로 작동 하는 한 서버 측 구현은 클라이언트와 관련이 없습니다 . 따라서 쿠키 자체 만으로는 API RESTless를 만들면 안되며 세션은 단순히 클라이언트에 대한 쿠키입니다.

내 가정이 잘못 되었습니까? 세션 쿠키를 RESTless로 만드는 이유는 무엇입니까 ?

먼저 몇 가지 용어를 정의하겠습니다.

• 평안한:

  이 섹션에서 "RESTful"로 설명 된 REST 제약 조건을 따르는 응용 프로그램을 특성화 할 수 있습니다. [15] 서비스가 필수 제한 조건을 위반하면 RESTful로 간주 할 수 없습니다.

  Wikipedia 에 따르면 .

• 상태 비 저장 제약 :

  다음으로 클라이언트-서버 상호 작용에 제약 조건을 추가합니다. 통신은 섹션 3.4.3 (그림 5-3)의 클라이언트-스테이트리스-서버 (CSS) 스타일에서와 같이 사실상 상태가 없어야합니다. 서버는 요청을 이해하는 데 필요한 모든 정보를 포함해야하며 서버에 저장된 컨텍스트를 활용할 수 없습니다. 따라서 세션 상태는 전적으로 클라이언트에서 유지됩니다.

  Fielding 논문 에 따르면 .

따라서 서버 측 세션은 REST의 상태 비 저장 제약 조건과 RESTfulness를 위반합니다.

따라서 클라이언트에게 세션 쿠키는 권한 부여 또는 다른 독점 헤더 대신 쿠키 헤더를 사용한다는 점을 제외하고 다른 HTTP 헤더 기반 인증 메커니즘과 정확히 동일합니다.

세션 쿠키를 통해 클라이언트 상태를 서버에 저장하므로 요청에 컨텍스트가 있습니다. 로드 밸런서와 다른 서비스 인스턴스를 시스템에 추가해 봅시다. 이 경우 서비스 인스턴스간에 세션을 공유해야합니다. 그러한 시스템을 유지 관리하고 확장하기가 어렵 기 때문에 확장이 심하지 않습니다 ...

제 생각에는 쿠키에는 아무런 문제가 없습니다. 쿠키 기술은 저장된 데이터가 모든 요청에 ​​의해 쿠키 헤더에 자동으로 첨부되는 클라이언트 측 저장 메커니즘입니다. 그런 종류의 기술에 문제가있는 REST 제약 조건을 모르겠습니다. 따라서 기술 자체에는 문제가 없으며 사용법은 문제입니다. Fielding은 왜 HTTP 쿠키가 좋지 않다고 생각하는지에 대한 하위 섹션을 작성했습니다 .

내 관점에서:

• RESTfulness에 대한 인증은 금지되지 않습니다 (그렇지 않으면 RESTful 서비스에 거의 사용되지 않음)
• 인증은 일반적으로 헤더에 요청에 인증 토큰을 보내서 수행됩니다.
• 이 인증 토큰은 어떻게 든 얻어야하고 취소 될 수 있으며이 경우 갱신해야합니다.
• 인증 토큰은 서버에서 검증해야합니다 (그렇지 않으면 인증이 아님).

당신의 관점은 꽤 견고했습니다. 유일한 문제는 서버에서 인증 토큰을 생성한다는 개념이었습니다. 그 부분은 필요하지 않습니다. 필요한 것은 클라이언트에 사용자 이름과 비밀번호를 저장하고 모든 요청과 함께 보내는 것입니다. HTTP 기본 인증 및 암호화 된 연결보다이 작업을 수행 할 필요가 없습니다.

• 그림 1.-신뢰할 수있는 클라이언트의 상태 비 저장 인증

모든 요청을 인증해야하기 때문에 서버 측에서 메모리를 통한 인증 캐시가 필요할 수 있습니다.

이제 이것은 당신이 작성한 신뢰할 수있는 클라이언트가 잘 작동하지만 타사 클라이언트는 어떻습니까? 사용자 이름과 비밀번호 및 사용자의 모든 권한을 가질 수 없습니다. 따라서 타사 클라이언트가 특정 사용자가 가질 수있는 권한을 별도로 저장해야합니다. 따라서 클라이언트 개발자는 타사 클라이언트를 등록하고 고유 한 API 키를 얻을 수 있으며 사용자는 타사 클라이언트가 일부 권한에 액세스 할 수 있습니다. 이름과 이메일 주소를 읽거나 친구 등을 나열하는 등 타사 클라이언트를 허용 한 후 서버는 액세스 토큰을 생성합니다. 이러한 액세스 토큰은 타사 클라이언트에서 다음과 같이 사용자가 부여한 권한에 액세스하는 데 사용할 수 있습니다.

• 그림 2.-타사 클라이언트의 상태 비 저장 인증

따라서 타사 클라이언트는 신뢰할 수있는 클라이언트 (또는 사용자로부터 직접)로부터 액세스 토큰을 얻을 수 있습니다. 그런 다음 API 키 및 액세스 토큰으로 유효한 요청을 보낼 수 있습니다. 이것이 가장 기본적인 타사 인증 메커니즘입니다. 모든 타사 인증 시스템 (예 : OAuth)의 설명서에서 구현 세부 정보에 대해 자세히 알아볼 수 있습니다. 물론 이것은 더 복잡하고 안전 할 수 있습니다. 예를 들어 서버 측에서 모든 단일 요청의 세부 정보에 서명하고 요청과 함께 서명을 보낼 수 있습니다. 실제 솔루션은 응용 프로그램의 요구에 따라 다릅니다.

우선, REST는 종교가 아니며 그렇게 접근해서는 안됩니다. RESTful 서비스에는 장점이 있지만, 애플리케이션에 적합한 REST의 원칙 만 따라야합니다.

즉, 인증 및 클라이언트 측 상태는 REST 원칙을 위반하지 않습니다. REST는 상태 전이가 상태 비 저장을 요구하지만 서버 자체를 의미합니다. 마음에 모든 REST는 문서에 관한 것입니다. 상태 비 저장의 기본 개념은 서버가 클라이언트가 아닌 상태 비 저장이라는 것입니다. 동일한 요청 (동일한 헤더, 쿠키, URI 등)을 발행하는 모든 클라이언트는 애플리케이션에서 동일한 위치로 이동해야합니다. 웹 사이트가이 서버 측 탐색 변수를 업데이트하여 사용자의 현재 위치를 저장하고 탐색을 관리하면 REST가 위반됩니다. 동일한 요청 정보를 가진 다른 클라이언트는 서버 측 상태에 따라 다른 위치로 이동합니다.

Google의 웹 서비스는 RESTful 시스템의 환상적인 예입니다. 요청 시마다 사용자의 인증 키가있는 인증 헤더가 전달되어야합니다. 서버가 인증 키의 상태를 추적하고 있기 때문에 REST 원칙을 약간 위반합니다. 이 키의 상태는 유지되어야하며, 더 이상 액세스 권한을 부여하지 않는 일종의 만료 날짜 / 시간이 있습니다. 그러나 게시물 맨 위에서 언급했듯이 응용 프로그램이 실제로 작동하려면 희생을해야합니다. 즉, 인증 토큰은 가능한 모든 클라이언트가 유효한 시간 동안 액세스 권한을 계속 부여 할 수있는 방식으로 저장해야합니다. 한 서버가 인증 키의 상태를 다른 부하 분산 서버가 해당 키를 기반으로 요청을 처리 할 수 ​​없을 정도로 관리하고있는 경우 REST의 원칙을 실제로 위반하기 시작했습니다. Google 서비스는 언제든지로드 밸런스 서버 A에 대해 휴대 전화에서 사용하고있는 인증 토큰을 가져 와서 데스크톱에서로드 밸런스 서버 B를 치고 여전히 시스템에 액세스 할 수 있으며 요청은 동일했습니다.

결론은 인증 토큰이 가능한 한 많은 REST 특성을 보존 할 수 있도록 일종의 백업 저장소 (데이터베이스, 캐시 등)에 대해 유효성을 검증해야한다는 것입니다.

나는 그 모든 것이 이해되기를 바랍니다. 또한 대표 상태 이전에 관한 Wikipedia 기사 의 제약 조건 섹션 을 확인하십시오 ( 아직없는 경우). REST의 신조가 실제로 논쟁하고있는 이유와 그 이유에 대해 특히 깨달았습니다.

쿠키는 인증 용이 아닙니다. 왜 바퀴를 재발 명합니까? HTTP에는 잘 설계된 인증 메커니즘이 있습니다. 쿠키를 사용하는 경우 HTTP를 전송 프로토콜로만 사용하므로 예를 들어 사용자에게 잘못된 인증을 제공했음을 알리기 위해 자체 신호 시스템 을 만들어야 합니다 (HTTP 401을 사용하는 것은 그렇지 않을 수 있으므로 올바르지 않습니다) Www-AuthenticateHTTP 사양에 따라 클라이언트에 공급 :)). 또한 Set-Cookie클라이언트에게만 권장 사항입니다. 내용은 저장 될 수도 있고 저장되지 않을 수도 있습니다 (예 : 쿠키가 비활성화 된 경우) Authorization.

또 다른 요점은 인증 쿠키를 얻으려면 먼저 어딘가에 자격 증명을 제공하고 싶습니까? 그렇다면 RESTless가 아닐까요? 간단한 예 :

• 당신은 시도 GET /a 쿠키없이
• 어떻게 든 인증 요청을받습니다
• 당신은 가서 어떻게 든 권한을 부여 POST /auth
• 당신은 얻을 Set-Cookie
• 당신이 시도 GET /a 와 쿠키. 그러나이 GET /a경우 dem 등적으로 행동합니까?

요약하면 일부 리소스에 액세스하고 인증이 필요한 경우 다른 곳이 아닌 동일한 리소스 에서 인증해야한다고 생각합니다 .

실제로 RESTfulness는 Universal Resource Identifier로 표시되는 RESOURCES에만 적용됩니다. 따라서 REST와 관련하여 헤더, 쿠키 등과 같은 것에 대해서도 이야기하는 것은 실제로 적절하지 않습니다. REST는 HTTP를 통해 일상적으로 수행 되더라도 모든 프로토콜에서 작동 할 수 있습니다.

주요 결정자는 다음과 같습니다. URI 인 REST 호출을 보내면 일단 호출이 서버에 성공적으로 도달하면 전환이 수행되지 않은 것으로 가정하여 해당 URI가 동일한 컨텐츠를 리턴합니까 (PUT, POST, DELETE) ? 이 테스트는 리턴 된 오류 또는 인증 요청을 제외합니다.이 경우 요청이 아직 서버에 요청하지 않았기 때문에 제공된 URI에 해당하는 문서를 리턴하는 서블릿 또는 애플리케이션을 의미합니다.

마찬가지로 POST 또는 PUT의 경우 지정된 URI / 페이로드를 보낼 수 있으며 메시지를 몇 번이나 보내든 관계없이 항상 동일한 데이터를 업데이트하여 후속 GET이 일관된 결과를 반환하도록합니까?

REST는 데이터를 전송하는 데 필요한 하위 레벨 정보가 아니라 애플리케이션 데이터에 관한 것입니다.

다음 블로그 게시물에서 Roy Fielding은 전체 REST 아이디어를 훌륭하게 요약했습니다.

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

RESTful 시스템은 하나의 정상 상태에서 다음 정상 상태로 진행되며, 이러한 각 정상 상태는 잠재적 인 시작 상태 및 잠재적 인 최종 상태입니다. 즉, RESTful 시스템은 단순한 규칙은 항상 REST에 있거나 하나의 RESTful 상태에서 다른 RESTful 상태로 전환되도록 규칙을 포함합니다. 시스템은 복잡한 상태 다이어그램 일 수 있지만 각 사용자 에이전트는 한 번에 하나의 상태 (현재 정상 상태) 만 볼 수 있으므로 각 상태는 단순하며 독립적으로 분석 할 수 있습니다. 사용자 OTOH는 언제든지 자신의 전환을 만들 수 있습니다 (예 : URL 입력, 북마크 선택,"편집기 등을여십시오.")

정보가 URI 및 POST 페이로드의 일부가 아닌 한 쿠키 또는 헤더를 통해 수행되는지 여부에 관계없이 인증 문제는 REST와 전혀 관련이 없습니다. 따라서 상태 비 저장 상태와 관련하여 애플리케이션 데이터에 대해서만 이야기하고 있습니다.

예를 들어, 사용자가 GUI 화면에 데이터를 입력 할 때 클라이언트는 입력 된 필드, 누락되지 않은 필수 필드 등을 추적합니다. 이것은 모든 클라이언트 컨텍스트이며 전송 또는 추적해서는 안됩니다. 서버에 의해. 서버로 전송되는 것은 하나의 RESTful 상태에서 다른 RESTful 상태로 해당 자원에서 전이가 발생하도록 IDENTIFIED 자원 (URI에 의해)에서 수정해야하는 완전한 필드 세트입니다.

따라서 클라이언트는 사용자의 작업을 추적하고 논리적으로 완전한 상태 전이만 서버로 보냅니다.

기본 액세스 인증은 식별 할 때마다 암호화 된 username : password를 사용하지만 RBAC에 필요한 것은 사용자가 특정 통화에 사용하려는 역할이기 때문에 기본 액세스 인증 인 HTTP 트랜잭션은 RBAC에 적합하지 않습니다. RBAC는 사용자 이름에 대한 권한이 아니라 역할에 대한 유효성을 검사합니다.

usernameRole : password와 같이 연결하려고 시도 할 수 있지만 이는 나쁜 습관이며, 사용자가 더 많은 역할을 가질 때 인증 엔진은 모든 역할을 연결하여 테스트하고 모든 호출을 다시 호출해야하기 때문에 비효율적입니다. 이는 RBAC의 가장 큰 기술적 이점 중 하나 인 매우 빠른 인증 테스트를 파괴합니다.

따라서 기본 액세스 인증을 사용하여 문제점을 해결할 수 없습니다.

이 문제를 해결하려면 세션 유지가 필요하며 일부 답변에 따르면 REST와 모순되는 것처럼 보입니다.

이것이 REST가 종교로 취급되어서는 안된다는 대답에 대해 제가 좋아하는 것입니다. 복잡한 비즈니스 사례, 예를 들어 의료 분야에서는 RBAC가 절대적으로 일반적이며 필요합니다. 모든 REST 도구 디자이너가 REST를 종교로 취급하기 때문에 REST를 사용하도록 허용하지 않으면 안타까운 일입니다.

나에게 HTTP를 통해 세션을 유지하는 방법은 많지 않습니다. 쿠키, sessionId와 함께 또는 sessionId와 함께 헤더를 사용할 수 있습니다.

누군가 다른 아이디어가 있다면 기뻐할 것입니다.

토큰에 인코딩 된 모든 필요한 정보가 토큰에 포함되어야한다고 생각합니다. 토큰을 확인하고 정보를 해독하여 인증합니다 https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

1. 세션은 RESTless가 아닙니다
2. http 용도로만 REST 서비스를 사용하거나 잘못 인식 했습니까? 쿠키 기반 세션은 자체 (!) http 기반 서비스에만 사용해야합니다! (예 : 모바일 / 콘솔 / 데스크톱 등 쿠키를 사용하면 문제가 될 수 있습니다.)
3. 타사 개발자에게 RESTful 서비스를 제공하는 경우 쿠키 기반 세션을 사용하지 말고 대신 보안 문제를 피하기 위해 토큰을 사용하십시오.