HTTP 인증 방식

1. Basic Authentication

• 사용자 이름 / 비밀번호를 Base64로 인코딩하여 Authorization 헤더에 포함하여 전송하여 인증하는 방식
• 매우 안전하지 않음, SSL / TLS와 함께 사용
• (Request 헤더에 표시될 때)
  Authorization : Basic (인코딩 된 내용)

2. Bearer Token Authentication

• 헤더에 토큰을 포함하여 전송 Authorization 헤더에 포함하여 전송하여 인증하는 방식
• JWT를 사용하여 인증
• 간단한 방식, 상태를 유지하지 않음, 확장성이 높음
• 토큰 노출 위험, 토큰 관리가 귀찮다
• (Request 헤더에 표시될 때)
  Authorization : Bearer ~

3. OAuth

• 토큰 기반 인증 방식, 사용자가 직접 자격을 증명 X 미리 인증을 받아서 토큰을 발급받고 이 토큰을 이용하여 API를 요청하는 방식 (현재 : OAuth2.0)
• Kakao / Naver / Git / Facebook

4. API Key

Key를 발급받아 서버에 전송하여 인증하는 방식

5. 세션 기반 인증(Session Based Authentication)

세션 아이디를 생성하고 클라이언트에 전달 후 클라이언트가 세션아이디를 헤더나 쿠키에 포함시켜 전송하여 인증

 

---

 

JWT(JSON Web Token)

클레임이라고 불리는 정보를 JSON형태로 안전하게 전송하기 위한 토큰 기반의 표준

• 인증과 정보 교환에 사용, 서명이 되어 있어서 신뢰성 확보가 가능

1. Header : 토큰의 타입과 사용된 알고리즘 정보를 담고 있음, Base64Url로 인코딩
2. Payload : 클레임 정보, 대상, 발행자, 만료 시간 등 다양한 정보가 포함됨, Base64Url로 인코딩
3. Signature : Header와 Payload, Secret Key를 사용하여 생성된 서명

장점

• 상태 유지 X(Stateless) : 서버가 클라이언트의 상태를 유지할 필요가 없음.
• 간단하고 자기 포함적 : 자신이 필요한 정보를 모두 가지고 있음.
• 확장성 : (동일한 시큐리티를 사용한다고 가정 시)여러 시스템에서 토큰 하나로 사용 가능함.

단점

• 크기 : 클레임이 많을수록 토큰의 크기가 커짐.
• 보안 : 서명은 되어있지만(신뢰성) 암호화는 되어있지 않음. -> 중요한 정보를 JWT에 포함하면 안 됨.
• 토큰 관리 : 만료 시간, 갱신 관리

 

jwt.io 접속하여 Header, Payload, Signature 확인 가능!

빨간색 - Header, 보라색 - Payload, 파란색 - Signature