42s_hoTechCourse 모의면접 후 - 06

김남형·2021년 4월 10일

모의 면접 참패!!!

4월9일 금요일 오늘은 모의면접을 봤습니다. 결과는 참패!! 흑흑

클러스터를 놀러다녔더니..

하라는 공부는 안하고 맨날 즐겁게 클러스터를 뛰어다니니... 당연한 결과였습니다.
조금만 놀고 공부 할걸.... 뒤 늦은 후회!!!! 그럼 뭐해 다 끝났는데~~!!
42s_HoTechCourse로 항상 지도편달 해주시는 이호준멘토님께 석고대죄라도 올려야 할 판.....

면접에서 탈탈 털린 부분 채우기!!

목표 : JWT, Index, HTTP 1.0과 1.1의 차이 확인하기
방법 : Document, RFC과 서적을 통해서 자료 정리하기

1. JWT? 존맛탱? 이해하기

그냥 JWT는 JWT라 생각 것이 온데....

알아보기 이전 저의 생각은 주변에서 주워 들은대로 JWT는 로그인하면 주는 토큰 같은 것이었습니다.
아마도 자세히 알아보지 않으면 저와 비슷하게 생각하고 있지 않을까 생각하며 정리해보기로 했습니다.

JWT의 정의란?

JWT(JSON WEB TOKEN)는 당사자간에 정보를 JSON객체로 안전하게 전송하기 위한 개방형 표준이라고 합니다.

JWT 공식 사이트에서 나오는 문장이지 간과하기 쉬운 그러나 사실 몰라도 상관없지만.....
Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens.

이 부분을 놓치기 쉬운데 RFC 문서보면 JWT는 권한, claims을 JWS, JWE를 통해 인코딩 한 JSON 객체라는 것 입니다.
JWS(JSON Web Signature)와 JWE(JSON Web Encryption)로 서명과 암호화 한 것이 JWT라는 것이다.

그래도 잘 모르시겠다구요?

이해하기 쉽게 설명하자면 JWT는 추상화 클래스라 할 수 있고, JWS와 JWE는 추상화 클래스를 마저 구현한 콘크리트 클래스라고 할 수 있습니다. 내가 사용 하는 JWT는 콘트리트 타입의 인스턴트라고 생각하시면 됩니다!
결론적으로 Header.Payload.Signature은 우리가 사용하는 JWS Compact Serialization 직렬화한 문자열이다.

그래도 어렵죠? 좀더 자세히 들어가보죠!

JWS Compact 직렬화에 대한 자세한 정리

JOSE Header(JSON Object Signing and Encryption) Header

토큰 발급자는 토큰 유형과 서명 알고리즘을 작성해야 합니다.
꼭 UTF-8로 인코딩되어야 합니다. JSON 기본 인코딩이 UTF-8이기 때문입니다.

JWS Payload

페이로드는 JSON이지 않아도 됩니다 하지만 통상적으로 JSON을 사용 합니다.

JWS Signature

JOSE 헤더에서 작성 된 alg에 따라 이전 단계에서 구성된 메시지로 서명 합니다.

JWT의 구조와 소개 - 벨로퍼트

JWT의 구조와 소개는 벨로퍼트님의 글로 대체하도록 하겠습니다.
구조와 소개는 벨로퍼트님의 블로그 글에 자세히 나와있기도 하고 공식 사이트글을 보더라도 자세히
알 수 있습니다. 전 그 이외에 RFC를 봐야 알 수 있는것들로 슥슥 채우겠습니다!!

JWT공식 사이트에서 이상한 점 발견!?

지금까지 열심히 JWT를 알아보고 적용하려고 했는데 갑자기 나오는 다른 이름의 토큰!!!!
Bearer 스키마를 사용하는 Authorization 헤더에 JWT를 전송해야 한다.
이 부분은 아래에서 Oauth 2.0을 파트에서 이야기 하도록 하겠습니다.

일반적인 JWT 사용자 인증 과정

일반적인 순서는 위와 같고 2번, 5번의 과정은 사용하는 프레임워크에 따라 다르게 구현 됩니다.
토큰의 서명을 확인 하는것은 CPU 싸이클을 사용하며 IO 또는 네트워크 액세스가 필요하지 않습니다.
이외에 JWT 토큰을 사용 했을 때 얻을 수 있는 이점과 단점은 다른 인터넷 자료들에 잘 나와있으므로 생략 하도록 하겠습니다.

💡 토큰 자체에 사용자 인증에 필요한 모든 정보를 포함하고 있어 별도의 인증 저장소가 필요 없다.
헤더 + 페이로드 + 시크릿키를 조합해서 해시해서 검증하기 때문에 위변조시 토큰이 무효화 됩니다.
다만 시크릿키가 노출 된다면 외부에서 토큰을 생성 할 수도 있습니다.

JWT를 이해하기 위한 꼭 읽어봐야 할 것들
JWT 공식 사이트
JWT RFC7519
JWS RFC7515
NHN Cloud - JWT를 소개합니다
JWT 자바 가이드
bearer Token RFC6750

Oauth 2.0

Oauth란

OAuth는 클라이언트가 리소스 소유자를 대신하여 보호 된 리소스에 액세스 할 수있는 방법을 제공합니다.
일반적으로 클라이언트가 보호 된 리소스에 액세스하려면 먼저 리소스 소유자로부터 권한 부여를 받은 다음 권한 부여를 액세스 토큰으로 교환해야합니다.
그리고 클라이언트는 리소스 서버에 액세스 토큰을 제공하여 보호 된 리소스에 액세스합니다.

💡 자원의 소유자인 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법입니다.

Bearer Token RFC를 보면!

결론적으로 우리는 OAuth 2.0 프레임워크를 사용하고 토큰의 유형으로 Bearer Token을 사용하는 것입니다.
그리고 Bearer Token이 우리가 사용하는 JWT이기도 합니다.

💡 JWS를 쓰는 이유는 TLS를 통해 전송 간 암호화를 사용해 JWE를 사용하지 않아도 되는 이유이다.
즉 비밀을 준수 해야 하는 경우 내용을 암호화 하는게 아니라 전송 계층을 암호화 된다는 것이다.

OAuth 2.0의 역할과 설명

💡 각각의 역할을 이해하지 못하고 토큰으로 인증과 권한을 부여 받는다고 생각하면 헷갈릴 수 있으니 꼭 숙지하고 아래의 흐름을 봐주세요!.

OAuth 2.0의 권한 승인 과정은 6단계로 간략하게 요략 할 수 있습니다.

자원에 대한 권한 요청

자원 소유자에게 직접 요청
권한 서버를 중개자로 간접 요청 (권장하는 방식 아래에서 설명 하겠음)

클라이언트에게 자원에 대한 접근 권한을 승인(4가지 권한 승인 방법이 있음)
클라이언트가 권한 서버에게 접근 토큰을 요청
권한 서버는 클라이언트를 인증 및 부여 받은 권한을 검증하고, 검증 된 경우 클라이언트에게 접근 토큰 발행
클라이언트가 자원 서버에게 접근 토큰으로 인증 및 요청
자원 서버는 접근 토큰을 검증하고, 검증 된 경우 서비스 제공

네가지 방법 중 추천하는 방법

권한 코드 승인으로 진행하는 방법에 대해 알아보겠습니다.
왜냐하면 저희가 사용하는 OAuth방식이 보통 권한 코드 승인 방법을 따르기 때문입니다.
기타 권한 승인 방식의 세부 단계는 RFC-6749 - The OAuth 2.0 Authorization Framework 참조하세요!