😎 알고 쓰자, JWT(Json Web Token).

김민주·2023년 8월 6일

JWT 토큰 인증, 안드로이드에서 구현하기

목록 보기

1/3

들어가기

안드로이드 개발자인 나는 로그인을 구현할 때 당연하게 jwt 토큰 인증방식을 써왔었다. jwt 토큰이 어떻게 구성되어있는지 왜 jwt 토큰을 사용해야하는지에 대한 고민을 하지 않았었다. 그렇다.. 개발자로서 성장할 자세가 안되어있었다.😢 과거의 나를 반성하고, 다른 사람들에게 공부한 것을 공유하고자 jwt 토큰에 관련된 글을 작성하기로 했다.

JWT 토큰이란?

JWT(Json Web Token)은 Json 객체에 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, 인터넷 표준 인증 방식이다. 공식적으로 인증(Authentication) & 권한허가(Authorization) 방식으로 사용된다.

여기서 일반 로그인 과정과 인증 방식을 헷갈릴 수 있다. 바로 jwt 프로세스를 살펴보자.

JWT 프로세스

사용자가 아이디와 비밀번호 혹은 소셜 로그인을 이용하여 서버에 로그인 요청을 보낸다.
서버는 비밀키를 사용해 json 객체를 암호화한 JWT 토큰을 발급한다.
JWT를 헤더에 담아 클라이언트에 보낸다.

여기까지가 JWT를 발급받기까지의 (로그인 전)과정이다. 로그인 이후에는 다음과 같은 과정이 이루어진다.

클라이언트는 JWT를 로컬에 저장해놓는다.
API 호출을 할 때마다 header에 JWT를 실어 보낸다.
서버는 헤더를 매번 확인하여 사용자가 신뢰할만한지 체크하고, 인증이 되면 API에 대한 응답을 보낸다.

그런데 로그인 후에 왜 매번 JWT를 헤더에 넣어서 보내야 할까? 비효율적이라는 생각이 들 수 있다. 매번 인증 과정을 거쳐야하는 이유는 HTTP의 특성 때문이다.

HTTP의 특성

Connectionless : 한 번 통신이 이뤄지고 난 후에 연결이 바로 끊어진다
Stateless : 이전 상태를 유지/기억하지 않는다

인터넷을 사용하는 우리는 HTTP 프로토콜을 사용해서 통신을 한다. 웹 페이지를 열 때도, 핸드폰 어플을 사용할 때도, 클라우드를 사용할 때도 HTTP 통신으로 서버와 클라이언트가 데이터를 주고 받는다. 그런데 이런 HTTP는 connectionless하고 stateless하다는 특성이 있다. 쉽게 설명하면 한 번 통신이 일어나고 나면 연결이 끊어진다는 것이고, 다시 연결해도 이전 상태를 유지하지 않아 과거에 어떤 정보를 보냈었는지 기억하지 못한다는 것이다. 즉, 화면을 이동하며 새로운 API를 요청하면 다시 신뢰할만한 사용자인지 인증하는 과정을 거쳐야하는 것이다.

매번 사용자가 인증하는 과정은 귀찮을 뿐만 아니라 통신이 느려지는 문제가 될 수 있다. 따라서 인증된 사용자가 어느 정도 기간동안 재인증 하지 않아도 되도록(로그인이 유지되도록) 만든 것이 Access Token이다.

Access Token은 jwt 토큰의 일종이기에 먼저 jwt 구조에 대해 설명하고 다음 챕터에서 Access token과 Refresh token에 대해 다루도록 하겠다.

JWT의 구조

JWT는 Header, Payload, Signature 3개로 구성되어 있다.

📌 Header

alg : Signature에서 사용하는 알고리즘
typ : 토큰 타입

Signature에서 사용하는 알고리즘은 대표적으로 RS256(공개키/개인키)와 HS256(비밀키(대칭키))가 있다. 이 부분은 auth0 공식 문서에서 자세히 설명해주고 있다.

📌 Payload

사용자 정보의 한 조각인 클레임(claim)이 들어있다.

sub : 토큰 제목(subject)
aud : 토큰 대상자(audience)
iat : 토큰이 발급된 시각 (issued at)
exp : 토큰의 만료 시각 (expired)

📌 Signature

Signature는 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 key를 이용해 암호한 값이다.

Header와 Payload는 단순히 Base64url로 인코딩되어 있어 누구나 쉽게 복호화할 수 있지만, Signature는 key가 없으면 복호화할 수 없다. 이를 통해 보안상 안전하다는 특성을 가질 수 있게 되었다.

앞서 언급한 것처럼 header에서 선언한 알고리즘에 따라 key는 개인키가 될 수도 있고 비밀키가 될 수도 있다. 개인키로 서명했다면 공개키로 유효성 검사를 할 수 있고, 비밀키로 서명했다면 비밀키를 가지고 있는 사람만이 암호화 복호화, 유효성 검사를 할 수 있다.

😋 직접 맛보기

https://jwt.io/ 에 들어가 token 값을 입력하면 현재 자신이 사용중인 jwt 토큰이 어떤 구조로 되어있는지 쉽게 눈으로 확인할 수 있다. 지금까지 줄곧 사용했던 토큰의 구조를 드디어 처음 영접했다..ㅎ
참고로 exp와 iat의 경우 DateTime에 마우스를 갖다 대면 정확한 날짜와 시간이 바로 나온다.

그런데 여기서 깨달아야할 것이 있다. header와 payload는 이렇게 누구나 쉽게 확인할 수 있기 때문에 이 부분들에는 중요한 정보를 담으면 안된다는 것이다!

장단점

📌 장점

로컬에 저장하기 때문에 서버 용량에 영향을 끼치거나 받지 않는다.
보다 안전하다. (공개키/개인키 or 비밀키를 통해 서명되기 때문에)
모바일 앱에서 사용하기 적합하다.
모바일 앱은 여러 플랫폼 및 기기에서 동작할 수 있고, 서로 다른 도메인에서 통신할 수도 있다. 이때 JWT를 사용하면 플랫폼 독립적으로 사용자 인증을 처리할 수 있기 때문에 적합하다.
네트워크 부하가 적다.
http헤더나 url 파라미터를 통해 간단하게 전송되기 때문이다.

📌 단점

토큰의 크기가 커질수록 트래픽에 영향을 미칠 수 있다.
토큰은 발급되면 만료 기간 변경이 불가능하므로 토큰 만료 처리를 구현해야 한다.

정리

사용 목적 : JWT 토큰은 사용자 인증과 로그인 유지를 위해 쓰인다
토큰의 구조 : Header, Payload, Signature
- Header: 서명 알고리즘 (공개키/개인키 or 비밀키)
- Payload : 토큰 정보(대상, 발급시각, 만료시각)
- Signature : (Header+Payload) 서명 (인증용)
장단점
- 장점 : 네트워크 부하가 적고 모바일 앱에 사용하기 적합하다
- 단점 : 토큰 크기를 신경써야하고, 만료 기간 처리를 따로 해줘야한다