오늘은 기존의 인증방법에 대해서 간단히 정리해 보고,

Token 인증방식에 대해서도 알아보도록 하겠습니다.

 

1. 기존 인증방법의 정리

1-1. 기존 인증 Flow

기존의 인증방법을 간단하게 정리해 보면 아래와 같은 Flow를 가지게 되는데요.

 

  • 로그인 요청시 DB에서 User를 조회하고, 맞다면, 세션을 만들어 줍니다.
    • 서버는 세션정보를 메모리에 저장하기도 하며, DB에 저장합니다.
  • 생성된 세션정보를 Response의 Header에 넣어서 전달해 줍니다.
    • Set-Cookie:sessiono=
  • Client는 Request 정보에 받았던 세션정보를 넣어 줍니다.
  • 받은 세션정보를 검증해서 이상이 없어면 접근하는 것을 허용해 줍니다.
    • 이 과정에서 검증을 위해 계속 인증 서버와 DB에 접근하게 됩니다.

 

1-2. 세션의 문제

서버에 세션값을 저장해 놓고, 지속적으로 확인해야 하는 문제가 있습니다.

예전 쿠키사용방식보다는 훨씬 보안이 좋지만, 서버사용에 부담이 발생합니다.

 

1-3. 예전 쿠키방식의 문제

위의 세션방식이 아닌, 쿠키를 사용하는 방식도 있었습니다.

쿠키는 브라우저에 저장되기 때문에, 수정해서 사용하면 문제를 일으킬 소지가 있는데요.

HTTP Only, Secure 옵션등을 설정해서, Javascript로 조작하는 것을 막는 방법으로,

XSS공격에 대비를 하면 무방비상태가 되지는 않습니다.

하지만, CSRF방식에 대한 공격에는 취약할 수 있습니다.

CSRF를 막기 위해서는 최소한 CORS를 특정 URL만 허용ㅇ하도록 해야합니다.

 

2. Token기반 인증시스템

이번에는 Token기반 인증시스템의 인증시스템의 Flow를 보도록 하겠습니다.

유저가 로그인인증을 하면, 서버에서 사인된 토큰을 발급하구요.

 

클라이언트에서 이 토큰을 저장한다음,

서버에서 물어볼 때 마다 헤더값에 토큰값을 전송해서 서버에서 검증받는 방식입니다.

이러한 방식의 Token인증시스템은 훨씬 안전할 뿐만아니라, 쿠키나 세션사용이 편하지 않은, 모바일 서비스에도 적합합니다.

 

  • 1. 로그인 요청이 이루어 지면,
    • 자체 인증시스템의 경우는 DB에서 유저를 조회한 후
      • 유효하면 Token을 Header에 전달해 줍니다.
        • Bearer Token
    • OAuth2를 이용하는 경우,
      • 유저가 소셜서비스의 UI에서 로그인을 하고,
        • Redirect Url과 인증코드를 발급받아 User가 전달받으면,
          • Redirect Url을 통해서 인증코드와 서비스서버가 가지고 있는 AppID와 SecretCode를 소셜서비스에서 제출
            • 소셜서비스서버에서 AccessToken과 Refresh Token을 받은 다음, Client에 전달
  • 2. Client는 Request를 할때, 받았던 token정보를 request 헤더에 담아서 전달합니다.
    • Authorization: Bearer Token

참고로 위에서 말한,  Bearer Token은 RFC6750에도 정의되어 있는데요.

hexadecimal 캐릭터를 이용하여서 직접 발급하는 곳도 있다고 하지만,

JWT라고 하는 JSON Web Token이 대부분 사용되고 있는 것으로 알고 있습니다.

Bearer Token 또는 Bearer 라고하면 JSON Web Token이라고 생각해도 될 정도입니다.

 

3. JWT Token 인증방식

3-1. JWT

JWT는 JSON Web Token의 줄임말입니다. 

이름에서 알 수 있듯이 Json타입으로 되어 있습니다.

이를 이용해서 위에서 언급했던 Token 기반 인증시스템을 구현할 수 있는데요.

 

JWT에서는 payload에 정보를 넣고, Signature를 통해서 해당 Token을 확인합니다.
이것을 이용하면, 인증이 필요한 때 항상 세션을 서버에서 확인받지 않고도,
인증부분을 해결할 수 있습니다.
이를 통해서 서버비용이나 부하도 줄일 수 있겠지요.

 

3-2. JWT의 구조

JWT는 Header, Payload, Signature로 구성되어있는데요.

각각 아래와 같은 의미를 가지고 사용됩니다.

 

구분 내용 예시
Header Signing 알고리즘(예>HMAC SHA256 or RSA 등) 과 어떤 타입의 토큰인가로 구성되며,
이 값들을 Base64Url encode 됩니다.
{
 "alg": "HS256",
  "typ": "JWT"
}
Payload 유저에 대한 상태나 Client에서 사용될 정보에 대한 내용을 넣을 수 있습니다.
{
  "sub": "77823423",
  "name": "Brown Park",
  "iat": 1516239022
}
Signature Signature자체도,
Header와 Payload 그리고 Secret Key로 구성되어져 있습니다.
이 중 Secret Key는 서버에 안전하게 저장되어 있어야만 합니다.
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),  secret key)

 

3-3. Token의 전송과 헤더

인증서버에서 받은 Access Token을 API에 접속하기 위해서 접속할 때 제출해야 하는데요.

Bearer Authentication이라고 합니다.

token의 bearer에게 인증을 해주기 위한 것 인데요.

OAuth2.0에 잘 나와있습니다.

 

해당 토큰은 request 헤더의 Authorization 필더에 넣어서 보내야 합니다.

Bearer라고 적혀있는 부분이 type을 적는 곳입니다.

 

Authorization: Bearer <액세스token>

 

3-4. Token 인증과정 Flow

Token은 위의 헤더를 이용하여서 아래와 같은 Flow를 거쳐 Response를 받게 됩니다.

 

  • 클라이언트가 Authorization헤더에 Bearer 타입과 토큰정보 입력
    • Authorization: Bearer <액세스token>
  • 서버에서 인증 정보를 확인하여 200(OK), 아니면 403(Forbidden) 으로 Response를 보낸다.

 

 

 

Bearer는 

 

 

3-5. JWT 단점

세션관리를 하는 데에 있어서 JWT가 서버에 상태를 저장하지 않으므로,
서버부하를 상당히 줄여준다는 면에서는 아주 좋습니다.
하지만 반대로 서버가 컨트롤 할 수가 없으므로,
클라이언트의 컴퓨터가 탈취당한 경우 Access Token의 유효시간까지는,
강제로 개별 클라이언트에 해당토큰을 무효화하기가 어렵습니다.
(JWT의 장점인 서버에 세션데이터를 넣지 않는다는 전제로)

위에서 애기한 액세스 토큰과 리프레쉬 토큰을 동시에 발급하는 경우도,
서버에 조회가 많아지는 단점이 있습니다.

 

 

 

 

 

 

728x90

+ Recent posts