REST API 로그인 패턴

181

나는 동사가 아닌 명사, URL에 구운 API 버전, 컬렉션 당 두 개의 api 경로, GET POST PUT DELETE 사용법 등을 사용하여 apigee 제안을 밀접하게 따르는 REST api를 만들고 있습니다.

로그인 시스템에서 작업하고 있지만 사용자를 로그인하는 적절한 REST 방법이 확실하지 않습니다. 이 시점에서 보안을 위해 노력하고 있지 않으며 로그인 패턴이나 흐름 만 있습니다. (나중에 HMAC 등으로 2 단계 oAuth를 추가 할 예정입니다.)

가능한 옵션

다음과 같은 POST https://api...com/v1/login.json
같은 것에 대한 PUT https://api...com/v1/users.json
내가하지 않은 것 ...

사용자 로그인에 적합한 REST 스타일은 무엇입니까?

api rest design-patterns

— 스콧로 넥크
소스

이것이 응답 형식입니다. .json은 서버에게 json으로 응답하도록 지시하고 .xml은 서버에게 xml 형식으로 응답하도록 지시합니다. 오히려? 뒤에 선택적인 매개 변수로 만듭니다. blog.apigee.com/detail/…

— Scott Roepnack

URL에서만 콘텐츠 협상이 이루어지지 않았으며 헤더에서만 가능했습니다. URL에서 캐싱 등의 이점을 잃어 버리는 것을 의미합니다.

— 오디드

@ScottRoepnack은 AcceptHTTP 헤더를 고려해야합니다 .

— Alessandro Vendruscolo

@Oded Accept헤더 를 사용했다면 , 또한 Vary: Accept캐싱에 영향을 미치지 않을 것입니다. 확장에 대한 연결은 이전에 논의 되었습니다 ; 그래도 Shonzilla의 답변에 동의합니다.

— cmbuckley

@Oded-이해할 수 없습니다. URL에 컨텐츠 유형을 지정하면 (쿼리 경로의 .json 접미 부 또는 type = json query param으로) 캐싱의 이점을 왜 잃게됩니까? 이 경우 "당신"은 누구입니까? 캐싱 혜택을 잃는 사람은 누구입니까? 쿼리 경로 또는 매개 변수에있는 내용에 관계없이 모든 쿼리 결과를 캐시 할 수있는 것 같습니다.

— Cheeso

답변:

138

Roy T. Fielding과 Richard N. Taylor의 현대 웹 아키텍처의 기본 설계 , 즉 모든 REST 용어의 작업 순서에는 클라이언트-서버 상호 작용에 대한 정의가 포함됩니다.

모든 REST 상호 작용은 상태 비 저장 입니다. 즉, 각 요청에는 선행 요청과 상관없이 커넥터가 요청을 이해하는 데 필요한 모든 정보가 포함됩니다 .

이 제한은 다음과 같은 네 가지 기능을 수행합니다.이 특별한 경우에는 1, 3이 중요합니다

1 일 :이 커넥터가 요청 사이의 애플리케이션 상태를 유지하기위한 어떤 필요 제거 하여 물리적 자원의 소비를 줄이고 확장 성을 개선을;
셋째 : 중개자가 서비스를 동적으로 재 배열 할 때 필요할 수 있는 요청을 개별적 으로보고 이해할 수 있습니다.

이제 보안 사례로 돌아가겠습니다. 모든 단일 요청에는 모든 필수 정보가 포함되어야하며 권한 부여 / 인증은 예외가 아닙니다. 이것을 달성하는 방법? 요청이있을 때마다 필요한 모든 정보를 유선으로 보내십시오.

이를 보관하는 방법 중 하나는 해시 기반 메시지 인증 코드 또는 HMAC 입니다. 실제로 이것은 모든 요청에 현재 메시지의 해시 코드를 추가하는 것을 의미합니다. 비밀 암호 키 와 함께 암호 해시 기능 으로 계산 된 해시 코드 . 암호화 해시 함수 는 사전 정의되거나 주문형 코드 REST 개념 (예 : JavaScript)의 일부입니다. 비밀 암호화 키 는 서버에서 클라이언트로 리소스로 제공해야하며 클라이언트는이 키를 사용하여 모든 요청에 대한 해시 코드를 계산합니다.

HMAC 구현 에는 많은 예제가 있지만 다음 세 가지에주의를 기울이고 싶습니다.

실제로 작동하는 방식

클라이언트가 비밀 키를 알고 있으면 리소스를 사용할 수 있습니다. 그렇지 않으면 임시 키 (상태 코드 307 임시 경로 재 지정)를 사용하여 비밀 키를 승인하고 가져 와서 원래 자원으로 다시 경로 재 지정합니다. 이 경우 클라이언트에게 권한을 부여 할 URL이 무엇인지 미리 알 필요 가 없으며 시간에 따라이 스키마를 조정할 수 있습니다.

이것이 올바른 해결책을 찾는 데 도움이되기를 바랍니다.

— 아킴
소스

MAC은 메시지의 신뢰성을 입증하고 무단 변경을 방지하기위한 것입니다. 사용자 인증과는 아무런 관련이 없습니다

— yrk

사전 에 " 로그인 URL " 을 몰라도 사용자 / 클라이언트 인증을 처리하는 방법 중 하나를 추가했습니다

— Akim

다음은 REST 서비스에 대한 무의 인증 예와 다른 두 개의 좋은 기사입니다 : blog.jdriven.com/2014/10/... technicalrex.com/2015/02/20/...

— 블라디미르 Rozhkov

TL; DR 각 요청에 대한 로그인은 API 보안을 구현하는 데 필요한 구성 요소가 아니며, 인증입니다.

일반적으로 보안에 대해 이야기하지 않고 로그인에 대한 질문에 대답하기는 어렵습니다. 일부 인증 체계를 사용하면 기존 로그인이 없습니다.

REST는 보안 규칙을 지시하지 않지만 실제로 가장 일반적인 구현은 3 방향 인증을 사용하는 OAuth입니다 (질문에서 언급했듯이). 적어도 각 API 요청에 따라 로그인 자체는 없습니다. 3 방향 인증에서는 토큰 만 사용합니다.

사용자는 API 클라이언트를 승인하고 오래 지속되는 토큰 형태로 요청을 할 수있는 권한을 부여합니다
Api 클라이언트는 수명이 긴 토큰을 사용하여 수명이 짧은 토큰을 얻습니다.
Api 클라이언트는 각 요청과 함께 단기 토큰을 보냅니다.

이 체계는 사용자에게 언제든지 액세스를 취소 할 수있는 옵션을 제공합니다. 실제로 공개적으로 사용 가능한 모든 RESTful API는 OAuth를 사용하여 구현했습니다.

로그인 측면에서 문제 (및 질문)를 구성해야한다고 생각하지는 않지만 일반적으로 API 보안에 대해 생각하십시오.

일반적으로 REST API 인증에 대한 자세한 정보는 다음 자원을 참조하십시오.

— 슬라 보
소스

예, OAuth! 매우 솔직한 대답, 받아 들여진 대답이어야합니다.

— Levite

REST 철학의 큰 부분은 API를 디자인 할 때 가능한 많은 HTTP 프로토콜의 표준 기능을 활용하는 것입니다. 이 철학을 인증, 클라이언트 및 서버에 적용하면 API의 표준 HTTP 인증 기능을 활용할 수 있습니다.

로그인 화면은 사용자의 사용 사례에 적합합니다. 로그인 화면을 방문하고, 사용자 / 암호를 제공하고, 쿠키를 설정하고, 클라이언트는 모든 향후 요청에서 해당 쿠키를 제공합니다. 웹 브라우저를 사용하는 사람은 개별 HTTP 요청마다 사용자 ID와 비밀번호를 제공 할 것으로 기대할 수 없습니다.

그러나 REST API의 경우 각 요청이 사용자에게 영향을주지 않고 자격 증명을 포함 할 수 있으므로 로그인 화면과 세션 쿠키가 반드시 필요한 것은 아닙니다. 클라이언트가 언제든지 협력하지 않으면 401"무단"응답이 제공 될 수 있습니다. RFC 2617 은 HTTP의 인증 지원에 대해 설명합니다.

TLS (HTTPS)는 옵션 일 수도 있으며 상대방의 공개 키를 확인하여 모든 요청에서 클라이언트를 서버로 인증 할 수 있습니다 (또는 그 반대도 가능). 또한 이는 보너스 채널을 확보합니다. 물론, 통신을하기 전에 키 페어 교환이 필요합니다. (이는 특히 TLS로 사용자를 식별 / 인증하는 것에 관한 것입니다. 공개 키로 사용자를 식별하지 않더라도 TLS / Diffie-Hellman을 사용하여 채널을 보호하는 것이 좋습니다.)

예 : OAuth 토큰이 완전한 로그인 자격 증명이라고 가정합니다. 클라이언트에 OAuth 토큰이 있으면 각 요청마다 표준 HTTP 인증에서 사용자 ID로 제공 될 수 있습니다. 서버는 처음 사용할 때 토큰을 확인하고 각 요청으로 갱신되는 유효 기간으로 검사 결과를 캐시 할 수 있습니다. 인증이 필요한 요청은 401제공되지 않은 경우 반환 됩니다.

— wberry
소스

"각 요청에는 개인 사용자에게 영향을주지 않으면 서 자격 증명이 포함될 수 있기 때문에"따옴표의 내용이 잘못되어 3 방향 인증 및 OAuth가 발명되었습니다. 서버에서 요청을 취소하는 메커니즘없이 각 요청에 자격 증명을 제공하면 SSL없이 사용하면 안전하지 않습니다.

— Slavo

사용자 개념이있을 때마다 어떤 사용자를 식별하기 위해 클라이언트에서 서버로 무언가를 전달해야합니다. OAuth 토큰은 실제 사용자 / 암호 조합 대신 "신임 정보"역할을 할 수 있습니다. TLS로 채널을 보호하는 것은 항상 좋은 일이지만, 거의 요점입니다. 쿠키를 사용하더라도 인증 헤더 대신 쿠키 헤더를 사용하여 모든 요청이있을 때마다 일종의 토큰이 서버로 전송됩니다.

— wberry

어떤 이유로 든 TLS 또는 OAuth를 사용하지 않는 경우 매번 사용자 / 암호를 보내는 것이 한 번만 보내는 것보다 더 나쁜가요? 공격자가 사용자 / 암호를 얻을 수 있으면 공격자는 세션 쿠키를 얻을 수도 있습니다.

— wberry

자격 증명 인 쿠키와 인증 헤더의 차이점은 쿠키가 항상 특정 도메인과 연결되어 있다는 것입니다. 이는 API가 쿠키를 수신하면 쿠키가 어디에서 왔는지 알 수 있음을 의미합니다 (이전의 동일한 도메인에서 작성 됨). 헤더를 사용하면 알 수 없으며 특정 검사를 구현해야합니다. 일반적으로 동의합니다. 둘 다 자격 증명이지만 자격 증명 전달이 로그인이 아니라고 생각합니다. 로그인은 문을 여는 활동입니다. 3 방향 인증의 경우 클라이언트의 첫 번째 승인 만 로그인됩니다.

— Slavo