# 인증 방식
# API Key
# 정의
서비스들이 거대해짐에 따라 기능들을 분리하면서 모듈이나 애플리케이션들 간의 공유와 독립성을 보장하기 위한 기능들이 등장하기 시작했다. 그 중 제일 먼저 등장하고, 가장 널리 보편적으로 쓰이는 기술이다.
API Key는 API 개발자가 API에 대한 액세스를 제어하는 데 사용하는 영숫자 문자열로, API는 두 소프트웨어 모듈 간에 데이터를 교환할 수 있는 통신 메커니즘이다.
# 동작 방식
- 사용자는 API Key를 발급받는다.
- 해당 API를 사용하기 위해 Key와 함께 요청을 보낸다.
- 애플리케이션은 요청이 오면 Key를 통해 유저 정보를 확인하여 누구의 Key인지, 권한이 무엇인지 확인한다.
- 해당 Key의 인증과 인가에 따라 데이터를 사용자에게 반환한다.
# 문제점
API Key를 사용자에게 직접 발급하고, 해당 Key로 통신을 하기 때문에 통신 구간이 암호화가 잘 되어 있더라도 Key가 유출된 경우 대비하기 힘들다. 따라서 주기적으로 Key를 업데이트 해야하기 때문에 번거롭고, 서로 매치가 안되는 예기치 못한 상황이 발생할 수 있다. 또한, Key 한 가지로 정보를 제어하기 때문에 보안 문제가 발생하기 쉬운 편이다.
# OAuth 2.0
# 정의
기존의 기본 인증인 아이디와 비밀번호를 사용하거나, 각 애플리케이션들이 각자 개발한 제각각인 인증 방식을 표준화한 인증 방식이다.
# 동작 방식
- 사용자가 애플리케이션의 기능을 사용하기 위한 요청을 보낸다. (로그인 기능, 특정 정보 열람 등)
- (로그인을 예시로 들었을 때) 애플리케이션은 해당 사용자가 로그인이 되어 있는지 확인하고, 로그인이 되어 있지 않다면 사용자를 인증 서버로 Redirection한다.
- 간접적으로 Authorize 요청을 받은 인증 서버는 해당 사용자가 회원인지, 그리고 인증 서버에 로그인 되어있는지를 확인한다.
- 인증이 되었다면 사용자가 최초 요청에 대한 권한이 있는지 확인하고, 이러한 과정을
Grant(승인)라고 한다. 대체적으로 인증 서버는 사용자의 의지를 확인하는Grant처리를 하게 되고, 사용자의 Grant가 확인되지 않으면 다시 사용자에게 Grant 요청을 보낸다. - 사용자가 Grant 요청을 받게 되면, 해당 인증 정보에 대한 허가를 결정한다. 해당 요청을 통해 다시 인증서버에 인가 처리를 위한 요청을 보낸다.
- 인증 서버에서 인증과 인가에 대한 과정이 모두 완료되면 애플리케이션에 인가 코드를 전해준다. 인증 서버는 해당 인가 코드를 자신의 저장소에 저장한다.
- 인가 코드는 짧은 시간 유지되기 때문에 애플리케이션은 해당 코드를 Request Token으로 사용하여 인증 서버에 요청을 보내게 된다.
- 해당 Request Token을 받은 인증 서버는 자신의 저장소에 저장한 인가 코드와 일치하는지 확인하고, 긴 유효 기간을 가지고 실제 리소스 접근에 사용하게 될 Access Token을 애플리케이션에 전달한다.
- 애플리케이션은 Access Token을 통해 리소스 서버(인증 서버X)에 요청할 수 있게 된다.
Grant란?
인가와는 다른 개념이다. 인가는 서비스 제공자 입장에서 사용자에게 사용자의 리소스나 기능에 대한 액세스 권한을 부여하는 프로세스지만, Grant는 사용자가 자신의 인증 정보(보통 개인 정보 등)를 애플리케이션에 넘겨줄지를 결정하는 과정이다.
# 문제점
통신에 사용하는 Token은 무의미한 문자열을 가지고 정해진 규칙 없이 발행되기 때문에 증명 확인이 필요하다. 따라서 인증 서버에 어떤 식이든 DB 접근이나 다른 API를 활용하여 접근하는 등의 유효성 확인 작업이 필요하다는 공증 여부 문제가 있다.
# JWT
JWT(JSON Web Token)는 인증 흐름의 프로토콜이 아닌 Token 작성에 대한 프로토콜이다. JWT는 인증 여부 확인을 위한 값, 유효성 검증을 위한 값, 그리고 인증 정보 자체를 담고 있기 때문에 인증 서버에 묻지 않고도 사용할 수 있다.
# 문제점
서버와의 통신을 통한 인증 확인이 필요 없기 때문에 생기는 장점들이 많지만, 토큰 자체가 인증 정보를 가지고 있어 민감한 정보는 인증 서버에 다시 접속하는 과정이 필요하다.