인증 방식
웹 서비스의 규모가 커지면서, 다양한 기능을 독립적으로 분리하고 공유하기 위해 여러 인증 방식이 등장했다. 대표적으로 API Key, OAuth2, 그리고 JWT 방식이 있다. 각 방식의 동작 원리와 장단점을 알아보자.
API Key
API Key는 초기의 인증 방식 중 하나로, 모듈이나 애플리케이션 간의 공유와 독립성을 보장하기 위해 사용된다. 다음은 API Key의 동작 방식과 문제점이다.
동작 방식
-
API Key 발급: 사용자는 서비스로부터 API Key를 발급받는다. 공공기관 API의 경우, 신청서 제출 후 관리자의 승인을 통해 발급된다.
-
API 요청: 사용자는 API를 사용할 때 API Key와 함께 요청을 보낸다.
-
Key 검증: 서버는 요청을 받은 후 API Key를 검증하여 사용자 정보를 확인하고, 해당 사용자의 권한을 확인한다.
-
응답: API Key가 유효하고 권한이 있다면 데이터를 반환한다.
문제점
- 보안 문제: API Key가 유출되면 보안에 취약할 수 있다. 주기적으로 Key를 업데이트해야 하며, 이 과정에서 문제가 발생할 수 있다.
- 단순한 보안: API Key 하나로 모든 인증을 처리하므로 보안에 문제가 생길 가능성이 높다.
OAuth2
OAuth2는 API Key의 단점을 보완하기 위해 등장한 방식으로, 주로 페이스북, 트위터 등의 SNS 로그인 기능에서 사용된다. OAuth2는 인증 과정이 추가되어 더욱 세분화된 독립적인 인증을 제공한다.
동작 방식
-
사용자 요청: 사용자는 애플리케이션의 기능 사용을 위해 요청을 보낸다. (예: 로그인)
-
로그인 확인: 애플리케이션은 사용자가 로그인되어 있는지 확인하고, 로그인되지 않았다면 인증 서버로 리디렉션한다.
-
인증 서버 처리: 인증 서버는 사용자가 로그인되어 있는지 확인하고, 로그인이 되어 있다면 사용자 권한(Grant)을 확인한다.
-
Grant 요청: 사용자가 인증 정보를 제공할지 결정하는 Grant 요청을 받는다.
-
Grant 승인: 사용자가 Grant를 승인하면, 인증 서버는 애플리케이션에게 인증 코드(인가 코드)를 전달한다.
-
Access Token 발급: 애플리케이션은 인가 코드를 사용하여 Access Token을 요청한다.
-
Access Token 확인: 리소스 서버는 Access Token을 통해 요청을 받고, 인증 서버에 해당 토큰의 유효성을 확인한다.
-
데이터 제공: 인증이 완료되면, 사용자는 요청한 데이터를 받는다.
문제점
- 구조적 복잡성: 기존 API Key에 비해 구조가 복잡하다. 토큰의 유효성을 검증하기 위한 추가적인 공증 작업이 필요하다.
- 유효 기간: Access Token의 유효 기간을 관리해야 하는 추가적인 부담이 있다.
JWT (JSON Web Token)
JWT는 토큰 작성에 대한 규약으로, 인증 정보 자체를 담고 있어 인증 서버에 접속하지 않고도 인증을 처리할 수 있다.
특징
- 정보 포함: 토큰 자체에 인증 정보와 유효성 검증 값을 포함하여 독립적으로 동작할 수 있다.
- 자급적 검증: 서버와 연결 없이 토큰 자체로 인증 정보를 확인할 수 있다.
문제점
- 민감 정보: 토큰에 민감한 정보를 포함할 경우 보안 문제가 발생할 수 있으며, 이러한 정보는 여전히 서버 측 확인이 필요할 수 있다.
So...
각 인증 방식은 고유한 장점과 단점을 가지고 있으며, 서비스의 특성에 맞게 적절한 방식을 선택하는 것이 중요하다. API Key는 단순하지만 보안에 취약할 수 있고, OAuth2는 보안을 강화하지만 구조가 복잡하다. JWT는 독립적인 인증을 제공하지만 민감한 정보를 다룰 때 주의가 필요하다.
