REST 및 인증 변형

REST 및 인증 변형

---

저는 현재 .net 용 REST 라이브러리를 작업 중이며 제가 가지고있는 개방 지점 인 REST 및 인증에 대한 의견을 듣고 싶습니다.

다음은 라이브러리와 함께 사용되는 RESTful 인터페이스의 예입니다.

[RestRoot("/user")]
public interface IUserInterface
{
  [RestPut("/")]
  void Add(User user);

  [RestGet("/")]
  int[] List();

  [RestGet("/get/{id}")]
  User Get(int id);

  [RestDelete("/delete/{id}")]
  void Delete(int id);
}

그런 다음 서버 코드는 인터페이스를 구현하고 클라이언트는 팩토리를 통해 동일한 인터페이스를 얻을 수 있습니다. 또는 클라이언트가 라이브러리를 사용하지 않는 경우 표준 HTTP 요청도 작동합니다.

HTTP 기본 인증을 사용하거나 인증 된 사용자가 필요한 요청에 토큰을 보내는 주요 방법이 있다는 것을 알고 있습니다.

첫 번째 방법 (HTTP 기본 인증)에는 다음과 같은 문제가 있습니다 (부분적으로 웹 브라우저에 따라 다름).

• 암호는 모든 요청과 함께 전송됩니다. SSL을 사용하더라도 일종의 "나쁜 느낌"이 있습니다.
• 암호는 요청 헤더와 함께 전송되기 때문에 로컬 공격자가 전송 된 헤더를 확인하여 암호를 쉽게 얻을 수 있습니다.
• 비밀번호는 브라우저 메모리에서 사용할 수 있습니다.
• 사용자 "세션"을 만료하는 표준 방법이 없습니다.
• 브라우저로 로그인하면 페이지의 모양과 느낌이 중단됩니다.

두 번째 방법의 문제는 구현 및 라이브러리 사용에 더 중점을 둡니다.

• 인증이 필요한 각 요청 URI에는 토큰에 대한 매개 변수가 있어야하며 이는 매우 반복적입니다.
• 각 메서드 구현에서 토큰이 유효한지 확인해야하는 경우 작성할 코드가 훨씬 더 많습니다.
• 인터페이스는 예를 들어 덜 구체적인 될 것이다 [RestGet("/get/{id}")]대 [RestGet("/get/{id}/{token}")].
• 토큰을 넣을 위치 : URI의 끝에? 뿌리 후? 다른 곳?

---

내 생각은 토큰을 URL과 같은 매개 변수로 전달하는 것이 었습니다 http:/server/user/get/1234?token=token_id.

또 다른 가능성은 매개 변수를 HTTP 헤더로 보내는 것이지만 이것은 내가 추측하는 일반 HTTP 클라이언트와의 사용을 복잡하게 만들 것입니다.

토큰은 각 요청에서 사용자 지정 HTTP 헤더 ( "X-Session-Id")로 클라이언트에 다시 전달됩니다.

그런 다음 이것은 인터페이스에서 완전히 추상화 될 수 있으며 인증이 필요한 모든 구현은 토큰 (주어진 경우)이 속한 사용자를 물어볼 수 있습니다.

이것이 REST를 너무 많이 위반할 것이라고 생각하거나 더 나은 아이디어가 있습니까?

---

나는 인증 세부 사항이 URI가 아니라 헤더에 있다고 믿는 경향이 있습니다. URI에 배치되는 토큰에 의존하는 경우 애플리케이션의 모든 URI가 토큰을 포함하도록 인코딩되어야합니다. 또한 캐싱에 부정적인 영향을 미칩니다. 지속적으로 변경되는 토큰이있는 리소스는 더 이상 캐시 할 수 없습니다. 리소스 관련 정보는 자격 증명과 같은 애플리케이션 관련 데이터가 아닌 URI에 속합니다.

웹 브라우저를 클라이언트로 타겟팅해야하는 것 같습니까? 그렇다면 HTTP Digest 액세스 인증을 사용 하거나 클라이언트에게 고유하게 식별하고 인증하기 위해 자체 SSL 인증서를 발급 하여 조사 할 수 있습니다. 또한 세션 쿠키가 반드시 나쁜 것이라고 생각하지 않습니다. 특히 브라우저를 다룰 때. 쿠키 처리 코드를 분리하고 나머지 응용 프로그램이 이에 의존하지 않도록하는 한 괜찮습니다. 키는 세션에 사용자의 ID 만 저장하는 것입니다. 서버 측 세션 상태를 남용하지 마십시오.

브라우저가 아닌 다른 클라이언트를 대상으로하는 경우 취할 수있는 접근 방식이 많이 있습니다. 저는 Amazon의 S3 인증 메커니즘 을 사용하여 운이 좋았습니다 .

물론 이것은 모두 매우 주관적입니다. 순수성과 REST를 편지에 따르는 것은 때때로 비현실적 일 수 있습니다. 이러한 동작을 최소화하고 격리하는 한 애플리케이션의 핵심은 여전히 ​​RESTful 일 수 있습니다. REST 정보 및 접근 방식의 훌륭한 소스로 RESTful 웹 서비스 를 적극 권장 합니다.

---

workmad3에 동의합니다. 세션 수명을 유지해야하는 경우 세션 리소스를 만들어야합니다. 사용자 자격 증명 (기본 인증 또는 본문 콘텐츠의 자격 증명)을 사용하여 해당 리소스에 게시하면 고유 한 세션 ID가 반환됩니다. / session / {id}에서 삭제하면 사용자가 로그 아웃됩니다.

세션 만료 시간을 제어하려는 경우. 새 세션을 만들 때 (세션 리소스에 게시) 서버는 응답에 쿠키를 설정합니다 (표준 set-cookie 헤더 사용). 쿠키에는 만료 시간이 포함됩니다. 쿠키 문자열은 서버에서 암호화되어야하므로 서버 만 해당 쿠키를 열 수 있습니다. 서버에 대한 모든 후속 요청은 쿠키 헤더에 세션 쿠키를 보냅니다. (클라이언트가 브라우저 인 경우 자동으로 수행됩니다). 서버는 모든 요청에 ​​대해 쿠키를 "갱신"해야합니다. 즉, 새로운 만료 시간으로 새 쿠키를 생성해야합니다 (세션의 시간 초과 연장). 사용자가 세션 리소스에 대해 delete를 호출 할 때 쿠키를 지워야합니다.

If you want your application to be more secured you can store the client IP in the cookie itself, so when a request arrives the server can validate that it was sent from the "original" client. But remember that this solution can be problematic when proxies are involved, because the server might "see" all the requests as coming from the same client.

---

The rest authentication I've seen treats the sessions as a REST resource for creation, destruction etc. and then the session ID is passed to and fro. The ones I've seen tend to use the session cookie for this as it's the only way to secure it really. If you pass the session id in the URL, you don't have any way of really authenticating it came from the correct client.

그러나 인증은 REST의 까다로운 문제입니다. 상태를 나타내는 데 필요한 모든 것이 URL의 REST 원칙을 위반하는 상태 형식을 URL 외부에 보관해야하기 때문입니다.

참고 URL : https://stackoverflow.com/questions/458482/rest-and-authentication-variants