토큰 (
token)
。Client-side에서 인증정보를 보관하는 방법.
▶서버가 아닌, 인증정보를client-side에 암호화하여 저장.
。서버에서토큰의 발급만 수행하고저장 & 관리하지 않아서 부하가 적다.
▶세션방식에 반해분산환경에서 유리
。Session기반 인증방식은클라이언트에서서버에 특정User에 대한 정보를 요청할때마다 일일이세션ID의 일치여부를 확인.
▶ 매요청마다Server의DB를 확인하는것이 부담이되므로Token기반 인증방식이 등장.
。HTTP Servcer는stateless특징으로 상대를 알 수 없다.
▶사용자는 매번요청시Authorization Header에토큰을 포함하고,서버는 전달된토큰이 해당서버에서 발급했는지 판단하기 위해검증을 수행
JSON 토큰(JWT: Json Web Token ) :
。웹에서Authentication과 정보교환 등을 수행하기위해 사용하는Token기반인증 방식
。클라이언트가 로그인 후서버가클라이언트에게 발급하여 제공
▶ 이후클라이언트에서 전송하는HTTP Request마다Authorization Header에JWT를 포함하여인증을 수행.
。클라이언트가Token을 보관하면서Stateless특징을 지니므로,Session이 필요없다.
▶ 또한Session처럼DB 조회없이Token만으로Authenticate가 가능.
。JWT의payload에 사용자 정보를 보관 가능.
。JWT Token은Request Authorization Header에Bearer {token}형식으로 저장
JWT 토큰종류
Access Token
。짧은 유효기간 5분
。Access Token의만료시간이 짧은 경우 유출되더라도 피해를 최소화하여 보안성이 좋지만, 자주 로그인해야하는 불편함이 존재
▶Access Token의유효기간을 짧게 구축하되만료시Refresh Token를 기반으로 새로운Access Token을 발급하는 방식으로 구현
▶사용자는Access Token이 만료되더라도 다시 로그인할 필요가 없다.
Refresh Token
。Access Token보다 긴 유효기간 ( 12시간 )
▶ 만료 시 로그인을 다시해야함
。서버에서 사용되어Access Token이만료된 경우 재발급하는 역할
▶클라이언트( =프론트엔드)에서 직접 다룰 일이 없으므로 보통HttpOnly 쿠키에 저장
JWT Token구조
。header.payload.signature로 연결되어 구분
。각 부분은Base64로인코딩
▶ https://www.jwt.io/에서 해석가능
Header
。typ(Token Type)과alg(Signature Algorithm)로 구성
▶Base64로인코딩되어 포함{ "typ": "JWT", // 토큰 타입 "alg": "HS256" // 서명 알고리즘 (HMAC-SHA256) }
Payload
。JWT의Claim을 포함하는 부분
▶Base64로인코딩되어 포함{ "iss": "example.com", "sub": "user123", "aud": "myapp", "exp": 1716239022, "iat": 1716235422, "role": "admin" // private claim }。
iss: ( issuer ) : 발급자
。sub: ( subject ): 사용자 ID
。aud: ( audiance ) : 대상자
。exp: ( expiration ) : 토큰만료시간
。iat( Issued at ) : 토큰발급시간
서명:Signature
。토큰을유효성 검증시 사용하는 고유한서명
▶JWT에Header.Payload를 서명 후Base64로인코딩하여 포함
。서명에 사용되는Private Key는 보안을 위해특정길이이상을 사용하도록 강제
▶비대칭키(RS256 , ES256) 등은 최소2048bit의 사용을 권장하므로KeyPairGenerator에서key 크기를2048 bit으로 생성하도록 설정.
Signature생성과정
1.Header,Payload를 각각Base64로인코딩
2.인코딩된 두문자열을.으로 결합
▶인코딩된Header.인코딩된Payload
3. 지정된알고리즘과Key로서명을 수행하여서명 Byte값을 생성
ex )RS256:SHA256으로private key를 활용하여서명
4.서명후 생성된byte값을base64로인코딩하여Signature생성
▶JWT = Header.Payload.Signature의Signature이 된다.
Signature검증과정
1.클라이언트로 부터 수신한JWT에서Header,Payload,Signature분리
。해당Header,Payload,Signature은 각각Base64Url로인코딩된 상태
2.Header를디코딩후 얻은JSON에서서명 알고리즘(alg)에서 허용된알고리즘인지검증
3.Signature을디코딩후 얻은서명 Byte값을서버의발급자의Public Key로 검증
4.검증후payload의 신뢰여부를 결정
。실패 시토큰을 거부
