API AUTHENTICATION 전략 종류
API AUTHENTICATION
4가지의 일반 적인 전략이 있다. REST API 인증에 있어서
- 베이직 인증
- 토큰 베이스 인증
- API Key 베이스 인증
- OAuth (Open Authorization)
여기서 4번을 authorization(권한부여) 이라고 불리는데 authentication(인증)과 뭐가 다른지도 알아보겠다.
시크릿과 키
시크릿은 정보 제공자(서비스업체)와 당신이 각각 갖고 있다. 당신이 갖고 있는 시크릿은 private key 라고 불리기도 한다.
당신의 시크릿을 서비스 업체에서 갖고 있다 하더라도 이는 유출 되더라도 암호화 되어있기에 원래로 복호화 할 수 없어야 한다. 이에 따라 암호를 잊어버리면 원래 암호를 알려주는 것이 아닌 리셋하는 이유이다.
퍼블릭 키와 프라이베이트 키
당신의 집 앞문은 public하다. 누구든지 당신의 집 앞문에 까지는 접근할 수 있다. 하지만 private한 키가 없지 않은 이상 집 안에 들어올 수는 없다. gmail에 접속은 누구나 가능하지만 패스워드(private key)가 없으면 접근 할 수 없다.
팩터(Factors)
팩터는 당신이 누구인지 인증합니다. 뭘 갖고 있고, 뭘 할수 있는지
아이디 패스워드 외에도 팩터라고 불리는 추가 적인 인증정보가 있습니다.
- 싱글팩터 — 아이디와 패스워드
- 투 팩터 — 당신만이 알고있는 질문의 답(가입시 작성)같은 다른 팩터가 아이디 패스워드와 조합
- 멀티 팩터 — 여러 팩터들이 조합된 인증방식
- 바이오메트릭 — 생채정보 인증
Auth 그리고 Auth
Authentication and Authorization 은 서로 다른 것 이다.
Authentication 은 서버에 로그인 하는 것이고
Authorization 은 서버의 리소스에 접근하는 것이다.
Authentication은 Authorization 이전에 일어나며 Authentication은 아이디, 패스워드, 그리고 언급했던 다른 팩터에 의해 일어난다. Authorization은 계정 권한에 의해 일어난다.
Authentication Schemes
REST API에서는 한번 로그인으로 충분하지 않습니다. stateless한 REST API는 당신이 누군지 기억하지 않으며 매번 요청마다 누군지 알려줘야합니다.
1. Basic Authentication
가장 간단한 방법으로 표준 HTTP 사양에는 헤더에 Authorization 이라는 필드가 있습니다. 이에 아이디와 패스워드를 넘겨주는 방식입니다.
이러한 방식은 카페의 wifi라던가 손쉽게 탈취될 수 있습니다. 이에 베이직 Authentication은 HTTPS/TLS에서 이루어져야 합니다. NOT HTTP!
SPA에서는 자바스크립트 코드가 노출 되기때문에 raw 한 아이디 패스워드를 저장해서는 안됩니다.
이에 SPA는 token-based authentication을 사용합니다.
2. Token Based Authentication
이 접근법은 클라이언트가 아이디와 패스워드를 서버에 넘겨줬을 때 서버에서는 이를 이용해서 토큰을 생성합니다.
그리고 이 토큰을 클라이언트에게 넘겨 줍니다.
이젠 유저가 매 요청마다 아이디 패스워드를 넘겨줄 필요 없이 토큰을 넘겨주면 됩니다. 이 토큰에는 날짜와 시간을 함께 인코딩 해서 특정 시간 이후에는 재사용이 불가능하게 하는 방법이 있습니다.
가장 유명한 포맷의 토큰은 JSON Web Tokens(JWT)입니다. JSON 이므로 key/value 페어로 이루어져 있고 이 키들은 claims로 불립니다.
3. API Key and Client Secret
클라이언트가 API에 접근하기 위해서는 API 그 자체에 가입해야 합니다. 가입 시 API서버는 Key 와 Secret을 각각의 가입된 클라이언트에게 부여합니다. 이 부여된 시크릿 으로 클라이언트는 서버에 접근 할 수 있습니다.
이는 매번 각각의 클라이언트에게 부여하기 어려우므로 이를 자동화 한 프레임 워크 인 OAuth 개발의 주된 이유입니다.
4. OAuth 2.0 (Open Authorization)
OAuth는 자동으로 키 생성과 교환을 진행합니다. 클라이언트가 API서버에 접근하기 위해서 권한 제공 업체에 로그인을 먼저 하라는 메시지가 표시됩니다.
한 실제 예를 들어 보겠습니다.
마이크가 그의 인터넷 뱅킹에 접근하려 했을 때 OAuth 시나리오를 살펴보겠습니다.
- 은행에 접근해서 아이디를 제출
- 은행에 해당 아이디의 리소스 접근 권한이 필요하다고 요청
- 은행은 다른 권한 제공 업체를 통해 엑세스 토큰을 마이크에게 제공
- 마이크는 은행에 해당 엑세스 토큰과 함께 아이디를 제공
- 은행은 해당 토큰과 아이디로 마이크 접근을 허용(권한 제공 업체가 보증함)