REST 기반 애플리케이션을위한 JWT 인증을위한 엔터프라이즈 패턴?

9

JWT 사양은 페이로드와 전송 방법 만 설명하지만 인증 프로토콜을 열어두고 유연성을 허용하지만 불행히도 유연성은 반 패턴 및 잘못된 설계로 이어질 수 있습니다.

JWT 인증을 위해 잘 생각되고 테스트 된 엔터프라이즈 패턴을 찾고 있는데 사용하거나 적용 할 수 있지만 완전한 것을 찾지 못했습니다.

내가 생각한 것은 :

Authorization 헤더가 충족되지 않거나 JWT 토큰이 유효하지 않거나 만료 된 경우 HTTP 401을 전송하십시오.
인증하려면 / login REST 채널을 사용하고 사용자 이름과 비밀번호를 JSON 객체로 보냅니다.
토큰을 유지하려면 / keepalive REST 채널을 사용하고 N (5) 분마다 호출하고 새 JWT 토큰을 수신하고 각 호출 후 기존 토큰을 교체하십시오 (M (15) 분 후에 토큰이 만료 됨)

그러나 나를 방해하는 것은 그 / keepalive 채널의 필요성입니다. 반면에 사용자가 자리를 비운 경우 (keepalive를 원할 경우 결정이 아직 충족되지 않은 경우) 인증이 만료되는 것을 막을 수 있습니다. 물론 추가 전화 및 프로토콜에 대한 추가 합병증입니다. 흥미로운 것은 서버가 자동으로 토큰을 연장한다는 것입니다. 세션 기반 환경에서는 타임 스탬프를 재설정하여 발생하지만 여기서는 서버가 매번이 아니라 매번 새 토큰을 보내야하지만 토큰이 R (예 : 10) 분 안에 만료 될 것입니다. 그러나 응답 본문에 배치하면 JSON 응답 프로토콜을 수정해야하므로 (솔루션이 투명하고 투명하지 않습니다) 클라이언트가 처리 할 수있는 추가 HTTP 헤더를 배치하는 것이 반드시 좋은 패턴은 아닙니다. 나는'

오픈 포인트에 응답하는 준비된 엔터프라이즈 패턴이 있습니까? 프로토콜 초안이 신뢰할만한 아이디어입니까? 처음부터 디자인보다 준비된 것을 사용하고 싶습니다.

rest authentication architectural-patterns

1

예. JWT는 많은 사람들이 자체 개발 한 '프로토콜'을 구현하고 입증 된 프레임 워크 코드를 제쳐 놓도록 이끌었습니다. 올바른 솔루션을 얻으려면 요구 사항을 명확히하는 것이 중요합니다. '세션'만료와 같은 소리가 필요합니다. 강제 로그 아웃이 필요합니까? 즉, 서버 측의 누군가가이 사용자를 로그 아웃하거나 사용자가 내 모든 세션을 로그 아웃한다고 말할 수있는 경우.

— joshp

4

JWT ( JSON Web Token 소개 )는 단지 토큰 형식이며 인증은 해당 사양에서 완전히 벗어난 것입니다. 실제로 인증 시스템 내에서 일반적으로 사용되지만 완전히 다른 시나리오에 사용할 수도 있으므로 해당 사양에 인증 관련 제약 조건을 포함하지 않는 것이 좋습니다.

인증에 대한 지침을 찾으려면 OpenID Connect 사양 제품군을 참조해야합니다 . 또한 시스템이 HTTP API로 구성되어 있고 자신 또는 타사 클라이언트 응용 프로그램에 해당 API에 대한 위임 된 액세스를 제공하려는 경우 OAuth 2.0 사양을 참조해야합니다 .

엔터프라이즈 시나리오에서 여전히 널리 사용되는 SAML 및 WS- 페더레이션과 같은 추가 인증 관련 프로토콜이 있지만 구현하기가 훨씬 더 복잡합니다.

특정 오픈 포인트 정보 :

베어러 토큰 인증 체계는 RFC 6750에 정의되어 있으며 요청 수행 방법 및 가능한 오류 코드에 대한 지침이 포함되어 있습니다 .
OAuth2 및 OpenID Connect는 모두 가능성을 고려하고 사용자 이름 / 암호를 토큰과 교환하는 방법을 정의합니다.
자체 포함 / 가치 토큰 (JWT) 수명 연장 문제는 OpenID Connect 및 OAuth2 내에서 새로 고침 토큰을 통해 해결됩니다 .

OAuth2 및 OpenID Connect는 일부 이전 제품보다 구현하기가 쉬운 것으로 보일 수 있지만 상당한주의를 기울이고 상당한 시간과 리소스를 소비하려는 경우에만 직접 구현할 수있을 정도로 복잡합니다. 일반적으로 많은 노력을 기울이는 타사 라이브러리 또는 서비스를 사용하는 것이 더 좋습니다.

마지막으로,이 프로토콜은 많은 시나리오를 다루므로 일부 상황에서는 과잉 상태 일 수 있습니다.

— 주앙 안젤로
소스

2

주의를 요하고 +1이 아니라 내재 된 질문에 대한 완전한 답변을 보증합니다.

— Paul

3

Keepalive 채널이 필요하다고 생각하지 않습니다. 페이로드에는 로그인시 토큰이 생성 될 때 서버가 제공 한 만료 정보 ( 표준 에 따라 exp키로 )가 포함될 수 있으며 권장됩니다 . 만료 된 토큰이 사용되면 (서명에 따라 서명이 확인 된 경우 토큰에있는 것을 신뢰하는 서버에 의해 결정됨) 서버는 단순히 HTTP 401로이를 거부하여 클라이언트에게 재 인증을 요구합니다.

한편 고객은 사전 예방적일 수 있습니다. 페이로드 섹션은 암호화되지 않으며 클라이언트가 읽을 수 있으므로 클라이언트는 요청이 만료 된 토큰과 함께 언제 전송되는지 확인할 수 있으므로 /login토큰이 만료되면 다시 호출 할 수 있습니다 .

또는 REST를 사용하면 하이퍼 미디어 정보를 '상태 엔진'으로 보낼 수 있으므로 원하는 경우 실제로 JWT를 한 번만 사용하고 만료 할 수 있습니다. 그러면 모든 요청은 hapi-auth-jwt2 와 같이 클라이언트에 대한 응답으로 컨텐츠 또는 응답 헤더에 리턴되는 새 JWT를 생성합니다 .

— 폴
소스