HTTP 헤더에서 JWT 토큰을 사용하여 리소스 서버에 대한 요청을 인증하고 있습니다. 리소스 서버와 인증 서버는 Azure에서 별도의 두 작업자 역할입니다.
클레임을 토큰에 저장해야하는지 또는 다른 방법으로 요청 / 응답에 첨부해야하는지에 대해 마음을 정할 수 없습니다. 클레임 목록은 서버의 데이터에 대한 액세스뿐만 아니라 클라이언트 측 UI 요소의 렌더링에도 영향을줍니다. 이러한 이유로 요청이 처리되기 전에 서버가받은 클레임을 인증하고 유효성을 검사하고 싶습니다.
클레임의 예는 CanEditProductList, CanEditShopDescription, CanReadUserDetails입니다.
JWT 토큰을 사용하려는 이유는 다음과 같습니다.
- 클라이언트 측 클레임 편집 (예 : 해킹 클레임 목록)에 대한 보호 기능이 향상되었습니다.
- 모든 요청에 대한 청구를 찾을 필요가 없습니다.
JWT 토큰을 사용하지 않으려는 이유 :
- 인증 서버는 앱 중심의 클레임 목록을 알아야합니다.
- 토큰은 해킹 엔트리의 단일 지점이됩니다.
- JWT 토큰이 앱 레벨 데이터 용이 아니라는 몇 가지 내용을 읽었습니다.
두 가지 모두 단점이있는 것 같지만이 주장을 토큰에 포함시키는 데 기울고 있으며 이전 에이 문제를 처리 한 사람들 이이 주장을 실행하고 싶습니다.
참고 : 모든 API 요청에 HTTPS를 사용하므로 토큰이 ‘충분히’안전 할 것 같습니다. AngularJS, C #, Web API 2 및 MVC5를 사용하고 있습니다.
답변
식별자 클레임 (사용자 ID 등) (jcrypt)을 jwt에 저장합니다.
그런 다음 서버 (API)에서 토큰을 얻으면 조회 서버 측 (db 또는 로컬 네트워크 API 호출)을 수행하고 사용자 ID (앱, 역할 등)에 대한 모든 연결을 검색 할 수 있습니다
그러나 jwt에 더 많은 것을 넣고 싶다면 각 요청마다 전송 될 가능성이 있기 때문에 크기에주의를 기울이지 만 민감한 클레임 데이터를 암호화해야합니다.
답변
인증 (사용자)과 권한 부여 (사용자가 수행 할 수있는 것)가 원하는대로 명확하게 나눠지지 않은 것처럼 들립니다.
인증 서버가 사용자에게 어떤 권한이 있는지 알지 못하게하려면 wchoward가 제안한 것처럼 해당 JWT의 클레임을 사용자 ID로 제한하십시오. 권한 서버로 알려진 다른 서버가 사용자에게 권한이있는 것을 찾도록 할 수 있습니다.
인증 단계는 클라이언트가 인증 토큰을 처음 제공 할 때 자원 서버가 수행 할 수 있습니다. 그런 다음 리소스 서버는 인증 클레임을 포함하는 클라이언트에 토큰을 보냅니다.
참고 : 두 JWT 모두 다른 키로 서명해야합니다.
장점 :
- 인증 및 권한 부여는 별도로 관리됩니다.
- 자원 서버는 각 요청에 대한 권한을 조회하지 않아도됩니다.
- UI는 권한을 볼 수는 있지만 편집 할 수는 없습니다.
범죄자:
- 클라이언트는 하나 대신 두 개의 토큰을 처리해야합니다.
- 권한 부여 서버를 추가하면 관리 할 다른 이동 부분이 추가됩니다.