RESTful API에서 토큰 갱신 / 세션 만료 처리

사용자 인증을 위해 JWT 토큰을 사용하는 RESTful API를 작성 중입니다 ( login끝점에서 발행하고 이후에 모든 헤더로 전송). 고정 된 시간 후에 토큰을 새로 고쳐야합니다 ( renew끝점을 호출 하면 갱신 된 토큰을 반환합니다) ).

토큰이 만료되기 전에 사용자의 API 세션이 유효하지 않을 수 있으므로 모든 엔드 포인트가 1) 토큰이 여전히 유효하고 2) 사용자 세션이 여전히 유효한지 확인하여 시작합니다. 클라이언트가 토큰을 로컬에 저장하기 때문에 토큰을 직접 무효화 할 수있는 방법이 없습니다.

따라서 모든 엔드 포인트는 클라이언트에게 두 가지 가능한 조건을 알려야합니다. 1) 토큰을 갱신 할시기이거나 2) 세션이 유효하지 않아 더 이상 시스템에 액세스 할 수 없다는 것입니다. 두 가지 조건 중 하나가 발생할 때 내 엔드 포인트가 클라이언트에게 신호를 보내는 두 가지 대안을 생각할 수 있습니다 (클라이언트가 옵션 중 하나에 적합하다고 가정).

1. 세션이 유효하지 않은 경우 http 401 코드 (권한 없음)를 반환하거나 토큰이 만료되어 renew엔드 포인트 를 호출해야 할 때 412 코드 (전제 조건 실패) 를 반환하면 200 (ok) 코드가 반환됩니다.
2. 세션이 유효하지 않거나 토큰이 만료되었음을 알리기 위해 401을 반환합니다. 이 경우 클라이언트는 즉시 renew엔드 포인트를 호출하고 200을 리턴하면 토큰이 새로 고쳐 지지만 renew401을 리턴하면 클라이언트가 시스템 외부에 있음을 의미합니다.

위의 두 가지 대안 중 어느 것을 추천 하시겠습니까? 어느 것이 더 표준적이고 이해하기 쉽고 RESTful 한 것입니까? 아니면 다른 접근법을 모두 추천 하시겠습니까? 두 옵션 중 하나에 명백한 문제 나 보안 위험이 있습니까? 답변에 귀하의 의견을 뒷받침하는 외부 참조가 포함 된 경우 추가 포인트.

최신 정보

여러분, 실제 질문에 집중하십시오- 갱신 / 세션 무효화를 알리는 두 가지 http 코드 대안 중 가장 좋은 것은 무엇입니까? 내 시스템이 JWT 및 서버 측 세션을 사용한다는 사실을 염두에 두지 마십시오. 매우 구체적인 비즈니스 규칙에 대한 API의 고유성이며 도움을 요청하는 부분은 아닙니다.)

이것은 인증 대 권한 의 경우처럼 들립니다 .

JWT는 요청의 발신자에 대한 암호로 서명 된 클레임입니다. JWT에는 "이 요청은 사용자 X에 대한 요청"및 "사용자 X에 관리자 역할이 있습니다"와 같은 클레임이 포함될 수 있습니다. 암호, 서명 및 TLS를 통해이 증명을 획득하고 제공하는 것은 인증 의 도메인이므로 귀하가 본인 임을 증명합니다.

이러한 클레임이 서버에 의미 하는 것 (특정 사용자 및 역할이 허용하는 것)은 권한 문제입니다 . 이 두 가지의 차이점은 두 가지 시나리오로 설명 할 수 있습니다. Bob이 회사 창고의 제한된 스토리지 섹션에 들어가고 싶지만 먼저 Jim이라는 경비원을 처리해야한다고 가정하십시오.

시나리오 A-인증

• Bob : "Hello Jim, 제한된 저장 공간에 들어가고 싶습니다."
• 짐 : "배지가 있습니까?"
• 밥 : "좋아, 잊어 버렸어."
• Jim : "죄송합니다. 배지가 없으면 입장 할 수 없습니다."

시나리오 B-권한

• Bob : "Hello Jim, 제한된 저장 공간에 들어가고 싶습니다. 여기 내 배지가 있습니다."
• Jim : "이봐 밥, 여기에 들어가려면 2 단계 허가가 필요합니다. 죄송합니다."

JWT 만료 시간은 다른 사람이 훔치는 것을 방지하는 데 사용되는 인증 장치입니다. 모든 JWT에 5 분의 만료 시간이있는 경우, 도난당한 경우 빨리 쓸모가 없어지기 때문에 별 문제가되지 않습니다. 그러나 "세션 만료"규칙에 대해서는 인증 문제와 같은 소리가납니다. 상태가 약간 변경되면 사용자 X는 더 이상 할 수 없었던 작업을 수행 할 수 없습니다. 예를 들어 사용자 Bob이 해고되었을 수 있습니다. 단순히 Bob이라는 것이 더 이상 회사에 대한 권한을 부여하지 않기 때문에 배지가 더 이상 Bob이라고 표시하는 것은 중요하지 않습니다.

이 두 가지 경우 별개의 HTTP 응답 코드를 가지고 401 Unauthorized와 403 Forbidden. 불행히도 이름이 지정된 401 코드는 자격 증명 누락, 만료 또는 취소와 같은 인증 문제를위한 것입니다. 403은 인증을위한 것입니다. 서버는 귀하가 누구인지 정확히 알고 있지만 귀하가하려는 일을 할 수는 없습니다. 사용자 계정이 삭제 된 경우 엔드 포인트에서 JWT로 무언가를 시도하면 403 Forbidden 응답이 발생합니다. 그러나 JWT가 만료되면 올바른 결과는 401 Unauthorized입니다.

일반적인 JWT 패턴은 "긴 수명"및 "짧은 수명"토큰을 갖는 것입니다. 수명이 긴 토큰은 수명이 짧은 토큰과 같이 클라이언트에 저장되지만 범위가 제한되어 있으며 수명이 짧은 토큰을 얻기 위해 인증 시스템 에서만 사용됩니다. 이름에서 알 수 있듯이 수명이 긴 토큰은 만료 기간이 매우 길며이를 사용하여 며칠 또는 몇 주 동안 새 토큰을 요청할 수 있습니다. 수명이 짧은 토큰은 설명하는 토큰으로 시스템과 상호 작용하기 위해 매우 짧은 만료 시간과 함께 사용됩니다. 수명이 긴 토큰은 Remember Me 기능을 구현하는 데 유용하므로 새로운 단기간 토큰을 얻기 위해 5 분마다 암호를 제공 할 필요가 없습니다.

"세션 무효화"문제는 수명이 짧은 JWT를 무효화하려고 시도하는 것과 비슷한 소리를 말합니다. 수명이 짧은 JWT는 서버 측에 거의 저장되지 않고 수명이 긴 JWT는 취소해야 할 경우 추적됩니다. 이러한 시스템에서 사용자가 기술적으로 자격 증명을 얻을 수 있지만 사용중인 토큰이 작업에 적합하지 않기 때문에 장기 토큰이 취소 된 자격 증명을 얻으려고하면 401 Unauthorized가 발생합니다. 그런 다음 사용자가 사용자 이름과 비밀번호를 사용하여 새 장기 토큰을 얻으려고하면 시스템에서 쫓겨 난 경우 403 Forbidden으로 응답 할 수 있습니다.

귀하의 API 세션은 RESTful 세계에 존재해서는 안되는 것입니다. RESTful 작업은 상태 비 저장 상태 여야하며 세션에 상태가 포함되므로 RESTful 세계에는 자리가 없습니다.

JWT는 사용자가 여전히 엔드 포인트에 액세스 할 수 있는지 여부를 판별 할 수있는 유일한 방법이어야합니다. 세션은 그 역할을 전혀 수행하지 않아야합니다. 그렇다면 RESTful API가없는 것입니다.

RESTful API를 목표로하고 JWT를 인증 요소로만 사용해야하는 세션을 모두 제거 할 경우 사용자는 엔드 포인트를 사용할 권한이 있는지 여부에 관계없이 401 Unauthorized응답 코드가 적합합니다. - 사용중인 갱신 신분증 renew과 함께 엔드 포인트를 호출해야합니다 grant_type=refresh_token.

최신 정보:

주석에서 현재 사용중인 JWT의 유효성 검사 흐름이 올바르지 않은 것 같습니다. 유효성 검사는 다음과 같습니다.

  Client        RESTful API      JWT Issuer
     |              |                |
     |----- 1. ---->|                | 
     |              |------ 2. ----->|-----
     |              |                | 3. |
     |              |<----- 4. ------|<----
-----|<---- 5. -----|                |
| 6. |              |                |
---->|----- 7. ---->|                |
     |              |------ 8. ----->|-----
     |              |                | 9. |
     |              |<----- 10. -----|<----
     |              |                |
     |              |------          |
     |              | 11. |          |
     |<---- 12. ----|<-----          |
     |              |                |
     .              .                .

1. Ask RESTful API for a JWT using login endpoint.
2. Ask Issuer to create a new JWT.
3. Create JWT.
4. Return JWT to the RESTful API.
5. Return JWT to Client.
6. Store JWT to append it to all future API requests.
7. Ask for data from API providing JWT as authorization.
8. Send JWT to Issuer for verification.
9. Issuer verifies JWT.
10. Issuer returns 200 OK, verification successful.
11. Retrieve and format data for Client.
12. Return data to Client.

서버 RESTful API는 인증으로 전송되는 토큰의 유효성을 확인해야합니다. 그 책임은 아닙니다 Client. 현재이 작업을 수행하지 않는 것 같습니다. 이런 식으로 JWT의 검증을 구현하면 세션이 전혀 필요하지 않습니다.

따라서 세션과의 REST 규칙을 이미 위반했을 때 어떤 접근 방식이 가장 RESTful인지 걱정하는 것이별로 의미가 없지만 비즈니스 요구 사항을 충족시키는 것으로 이해합니다.

REST 관점에서 클라이언트는 인증되거나 인증되지 않습니다. 아키텍처는 왜 그다지 중요하지 않은지 (불필요한 상태를 주입하고 있음) 주요 질문에 대답하기 위해 갱신 끝 점이 전혀 없습니다. 로그인 한 클라이언트는 항상 JWT를 보내고 서버는 항상 JWT를 확인하고 조치 200, 201 등을 기반으로 적절한 성공 코드를 보내어 승인하거나 401 또는 403으로 적절하게 거부합니다.

이제 JWT는 어떤 종류의 계정과 연결될 것입니다. 해당 계정이 잠겨 있거나 제한되어있을 수 있으므로 토큰 자체는 유효하지만 다른 곳에서는 여전히 조치가 거부됩니다. 비즈니스 규칙으로 인해 사용자 계정이 잠긴 경우 클라이언트에 제공하려는 정보의 양에 따라 여전히 401 또는 403입니다 (다른 비즈니스는 다른 의견을 가지고 있음).

마지막으로 계정이 잠금 해제되고 유효하지만 JWT를 해지해야한다고 주장하는 경우 401 또는 403을 계속 사용하여 유효하지 않은 JWT의 인증서 해지 목록과 같은 것을 유지합니다. JWT가 만료되었을 때 자체적으로 정리되는 한 (대부분의 데이터베이스에는이를 수행 할 수있는 방법이 있거나 앱 코드에 이벤트가있을 수 있음).