JWT 토큰에 사용자 클레임을 저장해야합니까?


18

HTTP 헤더에서 JWT 토큰을 사용하여 리소스 서버에 대한 요청을 인증하고 있습니다. 리소스 서버와 인증 서버는 Azure에서 별도의 두 작업자 역할입니다.

클레임을 토큰에 저장해야하는지 또는 다른 방법으로 요청 / 응답에 첨부해야하는지에 대해 마음을 정할 수 없습니다. 클레임 목록은 서버의 데이터에 대한 액세스뿐만 아니라 클라이언트 측 UI 요소의 렌더링에도 영향을줍니다. 이러한 이유로 요청이 처리되기 전에 서버가받은 클레임을 인증하고 유효성을 검사하고 싶습니다.

클레임의 예는 CanEditProductList, CanEditShopDescription, CanReadUserDetails입니다.

JWT 토큰을 사용하려는 이유는 다음과 같습니다.

  • 클라이언트 측 클레임 편집 (예 : 해킹 클레임 목록)에 대한 보호 기능이 향상되었습니다.
  • 모든 요청에 ​​대한 청구를 찾을 필요가 없습니다.

JWT 토큰을 사용하지 않으려는 이유 :

  • 인증 서버는 앱 중심의 클레임 목록을 알아야합니다.
  • 토큰은 해킹 엔트리의 단일 지점이됩니다.
  • JWT 토큰이 앱 레벨 데이터 용이 아니라는 몇 가지 내용을 읽었습니다.

두 가지 모두 단점이있는 것 같지만이 주장을 토큰에 포함시키는 데 기울고 있으며 이전 에이 문제를 처리 한 사람들 이이 주장을 실행하고 싶습니다.

참고 : 모든 API 요청에 HTTPS를 사용하므로 토큰이 '충분히'안전 할 것 같습니다. AngularJS, C #, Web API 2 및 MVC5를 사용하고 있습니다.


이것을 지금 읽고 있습니다 .... 가능하면 업데이트를 원합니다. 나는 똑같은 문제에 직면하고 있기 때문에 당신이 한 일에 관심이 있습니다. 사고와 일부 부품의 작동 방식이 누락되었습니다. 사용자는 승인 토큰을 얻지 만 청구가 어떻게 전달되어야하는지 ... 결과를 설명해 줄 수 있습니다. 아마도 도움이 될 것입니다.
Seabizkit

답변:


7

식별자 클레임 (사용자 ID 등) (jcrypt)을 jwt에 저장합니다.

그런 다음 서버 (API)에서 토큰을 얻으면 조회 서버 측 (db 또는 로컬 네트워크 API 호출)을 수행하고 사용자 ID (앱, 역할 등)에 대한 모든 연결을 검색 할 수 있습니다

그러나 jwt에 더 많은 것을 넣고 싶다면 각 요청마다 전송 될 가능성이 있기 때문에 크기에주의를 기울이지 만 민감한 클레임 데이터를 암호화해야합니다.


건배, DL. API 서버에서 역할 등을 캐시하거나 요청을받을 때마다 DB를 두 번 누르십시오. (예 : 역할에 대해 한 번, 요청중인 실제 데이터에 대해 한 번) 캐시하면 어떤 방법을 사용하는지 알고 싶습니다. 또한 이미 암호화 된 토큰을 '내부'로 사용자 ID를 추가로 암호화한다는 의미입니까? 감사.
Astravagrant

1
나는 아직까지 구현에 도달하지 못했습니다 :) 그렇습니다. 캐싱 서버를 사용하여 DB에 자주 충돌하지 않도록하고 역할이 변경되면 캐시를 제거하여 새로운 것을 허용합니다. 저장된 캐시를로드하기 위해 역할을 쿼리했습니다. 필자의 경우 아마도 오픈 memcached를 기반으로하지만 구성 및 사용하기 쉬운 Amazon AWS elsticache를 사용할 것입니다.
wchoward

또한 필요한 모든 정보를 리소스 서버에 가져 와서 토큰에 저장하지 않는 것이 좋습니다.
Mateusz Migała

그래서 모든 요청에 ​​대해 사용자 역할 ... 주장 ...을 얻습니다.이 기사가 가능하다는 것을 보여주는 기사 나 무언가를 지적 할 수 있습니까? 현재 세션을 사용하고 있지만 더 나은 방법을 찾고 있지만 모든 요청을 조회하는 것이 옳지 않은가요?
Seabizkit

3

인증 (사용자)과 권한 부여 (사용자가 수행 할 수있는 것)가 원하는대로 명확하게 나눠지지 않은 것처럼 들립니다.

인증 서버가 사용자에게 어떤 권한이 있는지 알지 못하게하려면 wchoward가 제안한 것처럼 해당 JWT의 클레임을 사용자 ID로 제한하십시오. 권한 서버로 알려진 다른 서버가 사용자에게 권한이있는 것을 찾도록 할 수 있습니다.

인증 단계는 클라이언트가 인증 토큰을 처음 제공 할 때 자원 서버가 수행 할 수 있습니다. 그런 다음 리소스 서버는 인증 클레임을 포함하는 클라이언트에 토큰을 보냅니다.

참고 : 두 JWT 모두 다른 키로 서명해야합니다.

장점 :

  • 인증 및 권한 부여는 별도로 관리됩니다.
  • 자원 서버는 각 요청에 대한 권한을 조회하지 않아도됩니다.
  • UI는 권한을 볼 수는 있지만 편집 할 수는 없습니다.

범죄자:

  • 클라이언트는 하나 대신 두 개의 토큰을 처리해야합니다.
  • 권한 부여 서버를 추가하면 관리 할 다른 이동 부분이 추가됩니다.

1
UI에서 권한을 확인하더라도 요청이 도착하면 서버 측에서 권한을 확인해야한다는 것을 잊지 마십시오.
차드 클라크
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.