API
서비스들이 거대해짐에 따라 기능들을 분리하기 시작하였는데 이를 위해 Module이나 Application간의 공유와 독립성을 보장하기 위한 기능들이 등장하기 시작
그 중 제일 먼저 등장하고 가장 보편적으로 쓰이는 기술이 API Key
동작 방식
- 사용자는 API Key를 발급 받음
- 해당 API 사용을 위해 Key와 함께 요청 보냄
- Application은 요청이 오면 Key를 통해 User 정보 확인하여 누구의 Key인지, 권한이 무엇인지 확인
- 해당 Key의 인증과 인가에 따라 데이터를 사용자에게 반환
문제점
API Key를 사용자에게 직접 발급하고 해당 Key를 통해 통신을 하기 때문에 통신구간이 암호화가 잘 되어 있더라도 Key가 유출된 경우에 대비하기 힘듦
-> 주기적으로 Key를 업데이트 해야해서 번거롭고 예기치 못한 상황이 발생할 수 있음
Key 한 가지로 정보를 제어하기 때문에 보안 문제가 발생하기 쉬운 편임
OAuth 2.0
API Key의 단점을 메꾸기 위해 등작한 방식으로, 인증을 위한 개방형 표준 프로토콜
대표적으로 페이스북, 트위터 등 SNS 로그인 기능요청하고 요청받는 단순한 방식이 아니라 인증하는 부분이 추가되어 독립적으로 세분화 이루어짐
동작 방식
문제점
기존 API Key 방식에 비해 조금 더 복잡한 구조를 가짐 -> 많이 개선됨
통신에 사용하는 Token은 무의미한 문자열을 가지고 기본적으로 정해진 규칙없이 발행되기 때문에 증명확인 필요.
-> 인증서버에 어떤 식이든 유효성 확인 작업이 필요하다는 공증 여부 문제가 있음. 뿐만 아니라 유효기간 문제도 있음.
JWT
JSON Web Token
인증 흐름의 규약이 아닌 Token 작성에 대한 규약
인증여부 확인을 위한 값, 유효성 검증을 위한 값, 인증 정보 자체를 담고 있기 때문에 인증서버에 묻지 않고도 사용 가능
문제점
토큰 자체가 인증 정보를 가지고 있기 때문에 민감한 정보는 인증서버에 다시 접속하는 과정이 필요
