인증(Authentication) 및 인가(Authorization) 공부 - 1

Hoseok Ryu·2021년 9월 14일
0

인증에 대한 업무를 앞둔 시점에서 JWT를 공부하다가 좋은 자료들이 있어서 공부하고 정리하려고 한다.

  1. intro to JWTs: https://jwt.io/introduction
  2. mozilla guidelines on OIDC https://infosec.mozilla.org/guidelines/iam/openid_connect.html
  3. JWT validation in the context of krakend https://www.krakend.io/docs/authorization/jwt-validation/
  4. example integration of krakend with keycloak: https://github.com/xyder/example-krakend-keycloak
  5. https://meetup.toast.com/posts/239

What is JWT

JWT 는 주로 인가(Authorization)정보 교환(Information Exchange) 에 사용된다. 특정 정보를 암호화한 문자열로 표현하고, 이 문자열을 주고 받으면서 복호화를 통해 인가받은 요청인지를 확인하는 데에 사용하는 것이다. 이 문자열은 URL의 어디에 들어가도 상관없게 디자인되어 있기 때문에 URL 이나 Header 중 어디에 들어가도 상관없다는 것 또한 장점이다. 어떤 정보들을 암호화시키길래 인가와 같은 중요한 것을 성공적으로 전달할까? 구조를 파헤쳐보자.

Structure of JWT

HEADER.PAYLOAD.SIGNATURE

JWT는 크게 3개로 구별된다. 각각에 대해 어떤 정보가 있는 지 예시를 통해 확인해보자.

1. Header

{
  "typ": "JWT",
  "alg": "HS256"
}

Header의 경우는 대부분 두 개의 큰 부분으로 표현된다.
1. the type of token, actually JWT
2. the signing algorithm being used such as HMAC, SHA256, or RSA.

2. Payload

Payload란 Claims를 포함하고 있다. Claim이란 JWT에 대한 내용(토큰 생성자(클라이언트)의 정보, 생성 일시 등)이나 클라이언트와 서버 간 주고 받기로 한 값들로 구성된다. Claim의 종류는 3가지로 나뉜다; registered, public, and private.

Registered Claim

필수는 아니지만 제공하면 좋은 것들이 포함되어 있다. 누가 만들었는 지, 언제 만들었는 지, 누가 듣는 지 등이 있으며 아래의 명령어들이 있다. (참고)

  • "iss" (Issuer) Claim
  • "sub" (Subject) Claim
  • "aud" (Audience) Claim
  • "exp" (Expiration Time) Claim
  • "nbf" (Not Before) Claim
  • "iat" (Issued At) Claim
  • "jti" (JWT ID) Claim

Public Claim

JWT를 사용할 사람들이 마음대로 만들 수 있는 속성들이다. 다만 IANA JWT Registry에 있는 것이나 URI에서 필요로 하는 것들과는 충돌을 피하는 것이 좋다.

Private Claim

Party 안에서 서로 공유하기로 합의한 내용들이다. register와 public이 아닌 모든 것들이다.

Warning

서명된 토큰의 경우 이 정보는 변조로부터 보호되지만 누구나 읽을 수 있습니다. 암호화되지 않은 경우 JWT의 페이로드 또는 헤더 요소에 비밀 정보를 넣지 마십시오.

3. Signature

Signature란 앞선 정보들에 대해 secret과 함께 암호화를 수행한 결과 문자열입니다. 서명이란 "이 문서가 올바름을 보증한다"라는 의미라고 생각하면 편할 것 같다. 추후에 이 정보를 이용해서 올바름을 판단한다.

4. Debugger

jwt.io Debugger을 통해 앞선 내용들을 공부해볼 수 있다!

How does JWT work?

인증 과정은 credential을 통한 본인 인증을 성공하면 JWT를 return 한다. 돌려받은 Token은 인증을 성공한 정보이기 때문에, 보안 이슈를 위해서 굉장히 조심히 다뤄야 한다. 유저는 이제 돌려받은 JWT를 이용해서 서버에 인가가 필요한 요청이 가능하다. 주로 Authorization header에 Bearer schema에 담아 JWT를 보내게 된다. (What is Bearer?)

Authorization: Bearer <JSON Web Token or OAuth Token>

이처럼 header에 정보를 담아 보낸다면 cookie를 사용하는 것이 아니기 때문에 CORS 이슈를 걱정할 필요가 없다.

Authorization flow using JWT

  1. 유저는 auth server에 authorization을 요청한다. (이 부분이 다른 auth flow와 다르다고 한다. 하지만 다른 걸 모르기 때문에 원본을 첨부한다.) => This is performed through one of the different authorization flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorization code flow.

  2. 만약 인가가 된다면 auth sever에서 token을 돌려준다.

  3. Token을 이용해서 protected resource에 접근한다.

profile
Research Engineer

0개의 댓글