JWT를 사용하여 Asp.net 웹 API에서 인증 구현

JWT를 사용하여 Asp.net 웹 API에서 인증 구현

---

JWT에 대해 읽고 있습니다.

그러나 내가 읽은 것은 인증 메커니즘이 아니라 인증 메커니즘의 중요한 구성 요소와 비슷합니다.

현재 작동하는 솔루션을 구현했지만 JWT를 사용 해보고 작동 방식을 확인하는 것뿐입니다. 그러나 지금 내가 추구하는 것은 그것을 어떻게 사용해야 하는가입니다. 내 경험상 기본적으로 고유 한 암호화 된 키를 제공하는 암호화 메커니즘입니다. 이 토큰 내부에 정보를 넣을 수도 있습니다.

모바일 응용 프로그램에서 사용할 ASP.NET 웹 API 2에서 구현하고 싶습니다.

그래서 1 단계 :

1. 앱 => 서버 : 로그인 (사용자, 비밀번호)
2. 서버 => 앱 : 로그인 확인, 여기에 JWT가 있습니다.
3. app => server : 내 프로필 가져 오기 (요청과 함께 JWT 전송) 서버는 JWT를 복호화하고 요청 ID를 결정합니다.

이제 이것은 나의 이해 일뿐입니다. 제가 완전히 잘못된 길을 가고있을 수 있습니다.

모든 요청에 ​​대해 인증 할 필요가없는 JWT의 이상입니까? 사용자 자격 증명을 한 번만 인증하면 (초기 로그인시) 서버가 JWT를 사용하고 DB에서 사용자 pw 및 사용자를 조회 할 필요가 없습니다.

사용자가 누구인지 확인하기 위해 JWT를 사용하고 싶습니다. 그런 다음 인증 한 후 인증합니다. 내가 아는 것처럼 새로운 MVC와 인증 및 권한 부여와 큰 혼란이 있습니다.

그래서 내 질문은 무엇입니까?

JWT를 사용하여 인증 메커니즘을 안전하고 효과적으로 구현하려면 어떻게해야합니까? 나는 작동하는 것처럼 보이고 보안에 대한 어떤 생각도 가지고 있지 않은 것을 기침하고 싶지 않습니다. 내 요구 사항에 맞는 보안 메커니즘을 설계 한 소스가 있다고 확신합니다.

내 요구 사항은 다음과 같습니다.

• 세션 당 한 번만 사용자 자격 증명에 대한 db를 확인해야합니까? 암호를 비교하기 위해 많은 리소스를 사용하는 bcrypt를 사용하기 때문입니다.
• 요청에서 사용자를 식별 할 수 있어야합니다. (즉, userId로 충분합니다) 그리고 바람직하게는 DB에 액세스하지 않고
• 요청을 처리하는 서버 측의 리소스와 관련하여 가능한 한 낮은 오버 헤드 여야합니다.
• 침입자가 이전 요청에 장치를 복사해야했다면 실제 사용자 데이터에 액세스 할 수 없어야합니다. (명백하게)

감사

---

JWT에 대한 이해가 좋습니다. 그러나 여기에 몇 가지 수정 사항과 몇 가지 권장 사항이 있습니다.

인증 및 승인

• JWT는 인증과 관련이 없습니다. DB 조회 및 암호 해싱은 JWT 생성시 인증 할 때만 발생합니다. 이것은 JWT와 직교하며 원하는 방식으로 할 수 있습니다. 개인적으로 Membership Reboot를 좋아 하는데 JWT 사용에 대한 좋은 예가 있습니다.
• 이론적으로는 사용자가 1 년에 한 번 비밀번호를 입력하고 JWT가 해당 연도 내내 유효하도록 할 수 있습니다. 이것은 최상의 솔루션이 아닐 가능성이 큽니다. JWT가 어느 시점에서 도난 당하면 사용자 리소스가 손상됩니다.

암호화

• 토큰은 암호화 할 수 있지만 암호화 할 필요는 없습니다. 토큰을 암호화하면 시스템의 복잡성과 서버가 JWT를 읽는 데 필요한 계산량이 증가합니다. 토큰이 휴지 상태 일 때 아무도 읽을 수 없도록 요구하는 경우 중요 할 수 있습니다.
• 토큰은 무결성을 보장하기 위해 항상 발급자가 암호화 방식으로 서명합니다. 이는 사용자 나 제 3자가 조작 할 수 없음을 의미합니다.

클레임

JWT에는 원하는 모든 정보가 포함될 수 있습니다. 사용자 이름, 생년월일, 이메일 등. 클레임 기반 승인으로이 작업을 수행합니다. 그런 다음 공급자에게 클레임 원칙의 클레임으로 JWT를 만들도록 지시하십시오. 다음 코드는 해당 Membership Reboot 예제에서 가져온 것이며 이것이 어떻게 수행되는지 보여줍니다.

public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
    var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
    UserAccount user;
    if (svc.Authenticate("users", context.UserName, context.Password, out user))
    {
        var claims = user.GetAllClaims();

        var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
        context.Validated(id);
    }

    return base.GrantResourceOwnerCredentials(context);
}

이를 통해 프로세서 집약적 인 인증 서비스를 사용하지 않고도 리소스에 액세스하는 사람을 정확하게 제어 할 수 있습니다.

이행

토큰 공급자를 구현하는 매우 쉬운 방법은 WebAPI 프로젝트에서 Microsoft의 OAuth 인증 서버 를 사용하는 것입니다. API 용 OAuth 서버를 만드는 데 필요한 기본적인 정보를 제공합니다.

사용자 를 훨씬 쉽게 제어 할 수있는 Thinktecture의 Identity Server 를 살펴볼 수도 있습니다 . 예를 들어 사용자가 한 번 인증 된 후 특정 시간 (한 달 정도) 동안 Identity Server에서 수명이 짧은 JWT를 계속받을 수있는 ID 서버를 사용하여 새로 고침 토큰을 쉽게 구현할 수 있습니다. 새로 고침 토큰은 취소 할 수있는 반면 JWT는 취소 할 수 있기 때문에 좋습니다. 이 솔루션의 단점은 Identity 서비스를 호스팅하기 위해 다른 서버 또는 두 대를 설정해야한다는 것입니다.

침입자가 리소스에 액세스하기위한 마지막 요청을 복사 할 수 없어야한다는 마지막 요점을 처리하려면 최소한 SSL을 사용해야합니다. 이렇게하면 전송중인 토큰이 보호됩니다.

If you are protecting something extremely sensitive, you should keep the token lifetime to a very short window of time. If you are protecting something less sensitive, you could make the lifetime longer. The longer the token if valid, the larger the window of time a attacker will have to impersonate the authenticated user if the user's machine is compromised.

---

I've written detailed blog post about configuring the OWIN Authorization server to issue signed JSON Web Tokens instead of default token. So the resource servers (Audience) can register with the Authorization server, and then they can use the JWT tokens issued by Token issuer party without the need to unify machineKey values between all parties. You can read the post JSON Web Token in ASP.NET Web API 2 using Owin

ReferenceURL : https://stackoverflow.com/questions/23674613/using-jwt-to-implement-authentication-on-asp-net-web-api