[REST API] 11. Token

Token 실습

1. Token

• Header, Payload, Sign으로 구성

• 여러 암호화 방식을 이용하여 Header와 Payload의 내용을 암호화하여 사용
• 암호화 방식이 Header에 명시되어 있기 때문에, 암호화를 진행할 때에는 Secret Key가 추가로 필요

• Sign은 바이트 값으로 전달되는데, 0 ~ 255 사이의 값을 가지기 때문에 ASCII로 표현 불가
• Base64 사용 ⇒ Header, Payload도 전부 Base64로 함께 Convert

2. Token의 형태

• header.payload.sign의 방식으로 이루어진 text

• JSON으로 주고 받음

• 검증 시에는 복호화가 가능하면 복호화를 진행

• 복호화가 불가능한 단방향 암호화(해시)일 경우 서버 내 Secret Key를 이용한 암호화를 입력 값과 함께 진행하여 sign의 값이 똑같은지 확인
• 같을 경우 인증이 가능

3. Token의 사용 용도

• Token은 사용자가 직접 받아야 하는 인증을 중개인 또는 대리인(서버)가 역할을 이어받아 인증을 대리로 진행할 수 있도록 하는 도구

• Token은 은행이 발행한 신뢰할 수 있는 정보(은행의 개인 키로 암호화됨)이므로, 중개인은 이 토큰을 은행에서 인증을 받음으로써 사용자의 신원을 활용할 수 있음

• 중개인이 Token을 검증할 수 있는 방법은 2가지가 존재
1. 은행의 공개 키로 복호화 (공개 키 검증, OIDC)
2. 은행에 직접 찾아가기

Token을 활용한 인증의 변화

• 처음 방식은 서버에서 직접 Token 발행 업체에게 검증을 받은 후 서비스를 제공하는 방식
• 유저가 인증이 필요한 요청을 보낼 때마다 업체에 검증해야 하므로 트래픽이 극심하게 증가

• 두 번째 방식은 처음에만 인증을 받은 후 서버의 토큰을 넘겨주는 방식
• 유저가 인증이 필요한 요청을 해도 서버의 토큰만 확인하면 되므로 서버 내부의 트래픽은 감소
• 유저가 가입/접속할 때마다 새로 토큰을 발행해주어야 하기 때문에 서버의 부하에 영향을 여전히 줌
• 서버에 유저 토큰의 정보를 저장하고 비교해야 하므로 Stateful 방식이 유지

• 세 번째 방식은 업체에서 지급한 토큰을 RSA 등의 공개 키 암호화 방식을 활용하여, 서버에서 업체의 공개 키로 검증하는 방식
• 이를 OIDC (Open ID Connect) 이라고 함
• 서버에서는 업체의 공개 키만 알면 검증이 가능하므로 더욱 간편하고, 토큰을 만들지 않아도 됨
• Stateless 서버로 전환 가능