내 질문은 정확하게 "정보를 확인하는 토큰이 WebApi 측에서 관리하는 방법을?"구현 JWT 인증
즉
• 그래도) 각 사용자마다 고유 한 비밀 키가 있습니까?
B) 그렇다면이 위치는 어디에 저장되어 있습니까?
C) 어떤 사람은 모든 세션에서 신선한 키가 생성된다고 말했습니다.
나는 이것이 어떻게 수행되어야하는지 또는 수행 될 수 있다고 생각 하는지를 명시 할 것이다.
1) 응용 프로그램은 Api (WebApi의 일부)에 로그인하기 위해 사용자 이름과 암호를 보냅니다.
2) Api가 데이터베이스의 자격 증명을 확인하고 JWT를 만듭니다.
3) 표준 헤더는 say header = { 'type': 'JWT', 'alg': 'HMAC'}로 생성됩니다.
4) 그런 다음 claim/payload 섹션이 만들어지고 해당 사용자의 고유 식별자가 포함됩니다.
5) 그런 다음 (header.claims) Base64URLEncoded이며 인코딩 된 정보 및 비밀 키를 매개 변수로 사용하여 HMAC 알고리즘을 사용하여 서명하는 방식으로 제공됩니다 (예 :).
6) 이제 헤더, 클레임, 서명 (이전 단계에서 획득 한)을 마침표로 연결하면 JWT가 생성됩니다.
7)이 JWT는 앱으로 다시 전송됩니다.
8) 다음 요청이있을 때 응용 프로그램은 자원에 액세스하는 동안이 JWT를 WebApi로 되돌려 보냅니다.
9) WebApi는 JWT를 검사하고 백 헤더, 주장을 해독합니다.
10) WebApi는 클레임에서 고유 사용자 식별자를 가져 와서이 사용자가 데이터베이스에 있는지 확인합니다.
11) 사용자가 발견되면 해당 사용자와 연관된 비밀 키가 사용자에게 데이터베이스에 저장됩니다. (등록시 생성 된 GUID 일 수도 있음)
12) 토큰이 만료되었는지 여부를 확인합니다. 이 정보는 클레임 / 페이로드에서 'exp'날짜 시간 등으로 사용할 수 있습니다.
13) 토큰이 아직 만료되지 않은 것으로 가정하면 WebApi는 헤더와 클레임/페이로드를 취하고 이전에 비밀 키를 사용하는 것과 같은 방식으로 JWT를 다시 생성합니다.
14) 이렇게 생성 된 JWT는 앱에서 전송 한 JWT와 일치합니다. 둘 다 일치하면 (서명) 토큰이 정확하고 템퍼링되지 않고 실제로이 사용자에게 WebApi에 의해 발급됩니다.
15) WebApi는 클레임 ID를 설정하고 리소스에 대한 액세스를 허용합니다.
데이터베이스의 사용자 식별자를 찾을 때마다 WebApi가 비밀 키를 유지하면서 로그인 할 때 정적 사용자 배열을 유지할 수도 있습니다.그래서이 배열로부터 정보를 얻을 수 있습니다. 사용자가 로그 아웃 할 때 정적 배열에서도 사용자가 제거됩니다. 배열 관리는 내가 지금 들어가기를 원하는 것이 아닙니다.
이것은 구현에 대한 나의 생각 일뿐입니다.
내가 다르게 수행 한 방식에서 얼마나 벗어 났는지 알고 싶습니다. 별도의 인증 서버를 만들고 싶지 않습니다. 나는 WebApi가 간단하지만 당연히 안전한 방법으로 이것을 관리하기를 원한다. JWT의 유효성을 검사하기 위해 .NET 4.5 용 Microsoft JwtSecurityTokenHandler를 사용합니다.