바퀴를 재발 명하지 않고 REST API 보안

바퀴를 재발 명하지 않고 REST API 보안

---

REST API를 설계 할 때 사용자를 먼저 인증하는 것이 일반적입니까?

내가 찾고있는 일반적인 사용 사례는 다음과 같습니다.

• 사용자가 데이터를 얻고 싶어합니다. 우리는 공유하고 싶습니다! 공개 API 키를 받고 읽어보세요!
• 사용자가 데이터를 저장 / 업데이트하려고합니다 ... woah 기다려! 당신은 누구입니까, 당신은 이것을 할 수 있습니까?

한 번 빌드하고 웹 앱, Android 애플리케이션 또는 iPhone 애플리케이션에서 사용할 수 있도록 허용하고 싶습니다.

REST API는 다음과 같은 요구 사항이있는 논리적 선택 인 것으로 보입니다.

내 질문을 설명하기 위해 간단한 예를 사용하겠습니다.

등급 속성 (정수 1 ~ 5) 이있는 데이터베이스에 항목이 있습니다.

REST를 올바르게 이해하면 다음과 같이 csv, xml 또는 json을 반환하는 내가 선택한 언어를 사용하여 GET 요청을 구현합니다.

http://example.com/product/getrating/{id}/

반환되는 JSON을 선택한다고 가정 해 보겠습니다.

{
  "id": "1",
  "name": "widget1",
  "attributes": { "rating": {"type":"int", "value":4} }
}

공개용 API에는 괜찮습니다. 나는 그 부분을 얻습니다.

많은 질문이있는 곳은 어떻게 이것을 보안 모델과 결합합니까? 나는 항상 내 사용자를 식별하는 세션 상태가있는 웹 앱 보안에 익숙해 져서 그들이 내게 무엇을 보내기로 결정하더라도 그들이 할 수있는 일을 제어 할 수 있습니다. 내가 이해하기 때문에 이것은 RESTful이 아니므 로이 경우 나쁜 해결책이 될 것입니다.

동일한 항목 / 등급을 사용하여 다른 예를 사용해 보겠습니다.

사용자 "JOE"가 항목에 등급 을 추가하려는 경우

다음을 사용하여 수행 할 수 있습니다.

http://example.com/product/addrating/{id}/{givenRating}/

이 시점에서 "JOE"가 제품 {id}에 {givenRating} 등급을 부여했다는 데이터를 저장하고 싶습니다.

질문 : 요청이 "BOB"가 아닌 "JOE"에서 온 것인지 어떻게 알 수 있습니까?

또한 사용자의 전화 번호와 같은보다 합리적인 데이터를위한 것이면 어떨까요?

내가 지금까지 가지고있는 것은 :

1) HTTP의 기본 제공 기능을 사용하여 모든 요청 (일반 HTTP 또는 HTTPS)에서 인증합니다.

이는 이제 모든 요청이 다음과 같은 형식을 취함을 의미합니다.

https://joe:joepassword@example.com/product/addrating/{id}/{givenRating}/

2) 개인 및 공개 키로 Amazon의 S3와 같은 접근 방식 사용 : http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

3) 어쨌든 쿠키를 사용하고 REST의 상태 비 저장 부분을 깨십시오.

두 번째 접근 방식이 나에게 더 나은 것처럼 보이지만이 모든 것을 정말로 재발 명해야 하는가? 해싱, 저장, 키 생성 등 모두 혼자서?

이것은 일반적인 웹 응용 프로그램에서 세션을 사용하고 전체 스택을 직접 다시 작성하는 것과 비슷하게 들립니다. 이는 일반적으로 특히 보안을 처리 할 때 "당신이 잘못하고 있습니다"를 의미합니다.

편집 : OAuth도 언급 했어야한다고 생각합니다.

---

5 년 후 편집

OAuth2를 사용하십시오!

이전 버전

아니요, 쿠키를 사용할 필요가 전혀 없습니다. HTTP Digest, OAuth 또는 Amazon의 AWS (복사하기 어렵지 않음)만큼 안전하지 않습니다.

쿠키를 확인해야하는 방식은 기본 / 다이제스트 / OAuth / 둘 중 어느 것이 든 상관없이 인증 토큰이지만 적절하지 않다는 것입니다.

그러나 세션 쿠키의 내용이 서버에서 반환하는 리소스의 내용에 영향을 미치지 않는 한 쿠키를 사용하는 것이 RESTful 원칙 그 자체에 어긋난다 고 생각 하지 않습니다.

쿠키는 사악하므로 사용을 중지하십시오.

---

"휴식"에 대해 걱정하지 말고 보안에 대해 걱정하십시오. 방법은 다음과 같습니다.

1 단계 : 사용자가 자격 증명으로 인증 서비스에 도달합니다.

2 단계 : 자격 증명이 체크 아웃되면 지문, 세션 ID 등을 반환하고 나중에 빠른 검색을 위해 공유 메모리에 넣거나 웹 서비스 처리 시간에 몇 밀리 초를 추가해도 괜찮다면 데이터베이스를 사용합니다. .

3 단계 : 모든 웹 서비스 요청에 대해 지문 및 세션 ID의 유효성을 검사하는 모든 웹 서비스 스크립트의 맨 위에 진입 점 호출을 추가합니다 .

4 단계 : 지문 및 세션 ID가 유효하지 않거나 시간이 초과 된 경우 인증으로 리디렉션합니다.

이것을 읽으십시오 :

RESTful 인증

---

3 년 후 편집

나는 Evert에 전적으로 동의하고 HTTPS와 함께 OAuth2 를 사용 하며 바퀴를 재발 명하지 않습니다! :-)

타사 클라이언트 용이 아닌 더 간단한 REST API로 JSON 웹 토큰 도 유용 할 수 있습니다.

이전 버전

Use a cookie anyway and break the stateless part of REST.

Don't use sessions, with sessions your REST service won't be well scalable... There are 2 states here: application state (or client state or session s) and resource state. Application state contains the session data and it is maintained by the REST client. Resource state contains the resource properties and relations and is maintained by the REST service. You can decide very easy whether a particular variable is part of the application state or the resource state. If the amount of data increases with the number of active sessions, then it belongs to the application state. So for example user identity by the current session belongs to the application state, but the list of the users or user permissions belongs to the resource state.

So the REST client should store the identification factors and send them with every request. Don't confuse the REST client with the HTTP client. They are not the same. REST client can be on the server side too if it uses curl, or it can create for example a server side http only cookie which it can share with the REST service via CORS. The only thing what matters that the REST service has to authenticate by every request, so you have to send the credentials (username, password) with every request.

• If you write a client side REST client, then this can be done with SSL + HTTP auth. In that case you can create a credentials -> (identity, permissions) cache on the server to make authentication faster. Be aware of that if you clear that cache, and the users send the same request, they will get the same response, just it will take a bit longer. You can compare this with sessions: if you clear the session store, then users will get a status: 401 unauthorized response...
• If you write a server side REST client and you send identification factors to the REST service via curl, then you have 2 choices. You can use http auth as well, or you can use a session manager in your REST client but not in the REST service.
• If somebody untrusted writes your REST client, then you have to write an application to authenticate the users and to give them the availability to decide whether they want to grant permissions to different clients or not. Oauth is an already existing solution for that. Oauth1 is more secure, oauth2 is less secure but simpler, and I guess there are several other solution for this problem... You don't have to reinvent this. There are complete authentication and authorization solutions using oauth, for example: the wso identity server.

Cookies are not necessarily bad. You can use them in a RESTful way until they hold client state and the service holds resource state only. For example you can store the cart or the preferred pagination settings in cookies...

참고URL : https://stackoverflow.com/questions/7238094/securing-rest-api-without-reinventing-the-wheel