서비스가 다양해지고 규모가 커지면서 기능들을 분리하기 시작했고, 이를 위해 모듈이나 애플리케이션들 간의 공유와 독립성을 보장하기 위한 사용자 인증 기능들이 나타나기 시작했다.
이러한 기능들 중 제일 먼저 등장하고 보편적으로 사용되는 기술은 API Key이다.
API Key
동작 방식
- 사용자는 API Key를 발급받는다.
- 해당 API를 사용하기 위해 Key와 함께 정보를 요청한다.
- 애플리케이션은 요청이 들어오면 Key를 통해 사용자의 정보를 확인하여 권한을 확인 후 정보를 반환한다.
문제점
- API Key를 사용자에게 직접 발급하고 해당 Key를 통해 통신을 하기 때문에 통신 구간의 암호화가 잘 되어 있더라도 Key가 유출된 경우를 대비하기 힘들다.
- 때문에 Key를 주기적으로 업데이트해야 하기에 번거롭다.
- Key 한 가지로 정보를 제어하기 때문에 보안 문제가 발생하기 쉽다.
API Key의 문제점을 개선하기 위해 OAuth 방식이 등장했다.
OAuth
Key 값을 통해 요청하고 응답받은 단순한 방식이 아니라 인증하는 부분이 추가되어 독립적으로 세분화가 이뤄졌다.
OAuth는 사용자가 비밀번호를 클라이언트에게 직접 제공하지 않고, 인증 및 권한 부여를 위한 토큰 기반 시스템을 사용한다.
동작 방식
- 사용자는 클라이언트에 접속하여 자신의 계정에 대한 인증을 요청한다.
- 클라이언트는 사용자를 인증 서버로 리다이렉션 한다.
- 사용자는 인증 서버에 로그인한다.
- 사용자 인증이 완료되면, 클라이언트는 인증 서버로부터 인증 코드를 받는다.
- 클라이언트는 받은 인증 코드와 함께 액세스 토큰을 요청한다.
- 인증 서버는 요청된 인증 코드를 검증하고, 액세스 토큰을 발급한다.
- 클라이언트는 발급받은 액세스 토큰을 사용하여 사용자의 데이터나 서비스에 접근한다.
- 일정 시간이 지나면 액세스 토큰이 만료되므로, 클라이언트는 새로운 액세스 토큰을 요청하여 갱신한다.
+--------+ +---------------+
| |--(1)- Authorization Request ->| |
| | | Authorization |
| |<-(2)-- Authorization Grant ---| Server |
| | | |
| | +---------------+
| |
| | +---------------+
| |--(3)-- Authorization Grant -->| |
| Client | | Resource |
| |<-(4)----- Access Token -------| Server |
| | | |
| | +---------------+
| |
| | +---------------+
| |--(5)----- Access Token ------>| |
| | | |
| |<-(6)--- Protected Resource ---| |
+--------+ +---------------+
문제점
인증 방식을 통해 좀 더 복잡한 구조를 가지지만, 통신에 사용되는 Token은 무의미한 문자열을 가지기 때문에 유효성을 확인하는 작업이 필요하다.
JWT(JSON Web Token)
JWT는 인증 흐름의 규약이 아닌 Token 작성에 대한 규약이다. 기본적으로 Access Token은 의미가 없는 문자열로 이뤄져 있어 Token의 유효성을 매번 확인해야 하는 것에 반해, JWT는 유효성 검증을 위한 값, 인증 여부를 확인하는 값 그리고 인증 정보 자체를 담고 있기 때문에 인증 서버에 묻지 않고 사용할 수 있다.
구성
- Header(헤더)
- 토큰의 유형: JWT임을 나타낸다.
- 사용된 해싱 알고리즘: 토큰을 서명할 때 사용된 알고리즘을 지정한다. (HMAC, SHA256, RSA)
- Payload(페이로드): 클레인이라고 불리는 정보들이 담겨 있다. 클레임은 토큰에 대한 주장을 나타낸다.
- 등록된 클레임: 토큰에 대한 정보를 제공하기 위해 이미 정의된 클레임이다.
- 공개 클레임: 공개적으로 사용되는 클레임들로, 충돌을 피하기 위해 URI 형식으로 이름을 지정한다.
- 비공개 클레임: 토큰을 주고받는 당사자간에 서로 합의한 클레임이다.
- Signature(서명): 서명은 헤더와 페이로드를 인코딩한 후, 비밀키를 사용하여 서명된다. 서명은 토큰이 위/변조되었는지 확인하는 데 사용된다.
"Header.Payload.Signature" 형식으로 구성되어 있다.
각 부분은 Base64로 인코딩 된다.
이러한 구성 요소는 JWT를 안전하게 전송하고, 토큰이 변조되지 않았음을 확인하는 데 사용된다.
문제점
서버에 직접 연결하여 인증을 확인하지 않아도 되지만, 민감한 정보를 다루는 경우에는 인증 서버에 다시 접속하는 과정이 필요하다.
OAuth와 JWT는 함께 사용되기도 합니다. OAuth는 클라이언트가 서비스에 대한 액세스 권한을 얻는데 사용되고, JWT는 이러한 권한을 증명하기 위한 토큰으로 사용됩니다.
OAuth는 인증 및 권한 부여 프로토콜이고, JWT는 안전한 데이터 전송을 위한 토큰 포맷입니다.
'Web' 카테고리의 다른 글
| Cookie와 Session, 왜 사용하지? (0) | 2024.03.20 |
|---|