2021-05-27 :: RESTful API에 로그인 하기

https://restcookbook.com/

REST가 요즘 뜨겁다. REST가 마침내 API 프로그래머들로 재발견되었다. 하지만 REST가 첫 생각처럼 그렇게 쉽지는 않다. HATEOAS를 다루면서 요구되는 일정한 인터페이스 아래 코드를 짜는 것은 상당히 까다롭고, 결국 사람들은 이전의 restful하지 못한 형태로 돌아가고는 한다. 하지만 그럴 필요는 없다. REST에 대해 제대로 알고 난 뒤에는 당신 역시 REST를 좋아할 것이다.

 

RESTful API에 로그인 하기

사용자가 RESTful APi에 접속해서 허락된 자원에게만 접근할 수 있도록 하기 위해서 무엇이 필요할까?

RESTful한 서버와 그렇지 않은 서버의 가장 큰 차이점 중 하나는 RESTful 설정 안의 세션 상태가 사용자 측에 있고 서버 자체는 상태가 없다(stateless)는 점이다. 이러한 점에서 사용자는 요청을 하기 위해서 필요한 모든 정보를 제공해야 한다.

기본 HTTP 인증 사용하기

당신의 credential들이 인코딩 되었다 하더라도 그것이 암호화 된 것은 아니다. 기본 인증으로 부터 유저의 이름과 비밀번호를 빼내는 것은 매우 쉽다. SSL/TLS이 아닌 일반 HTTP에서는 이와 같은 기본 인증을 사용해서는 안된다.

HMAC

기본 인증의 가장 큰 단점 중 하나는 매 요청마다 비밀번호를 함께 보내야 한다는 점이다. 또한 이러한 요청은 헤더와 바디의 침입으로부터 안전하지 못하다. HMAC(해쉬 기반의 메시지 인증)을 이용하면 이를 방지할 수 있다. 요청 시 비밀번호를 그대로 보내기 보다 해싱한 뒤 추가적인 정보를 덧붙여 전송하는 것이다. 만약 당신이 username이 "johndoe", 비밀번호가 "secret"인 credential을 통해 보호된 페이지인 /users/johndoe/finalcialrecords에 접근한다고 가정해보자. 먼저 우리가 아는 모든 정보를 가져와서 다음을 덧붙여야 한다.

GET+/users/johndoe/financialrecords

여기서 우리는 단순히 HTTP 동사와 실제 URL을 덧붙였다. 우리는 여기에 현재 timestamp, 난수 혹은 칩입을 방지하기 위해 메시지의 md5를 추가할 수 있다. 다음으로 우리는 hmac을 생성한다.

digest = base64encode(hmac("sha256", "secret", "GET+/users/johndoe/financialrecords"))

이 다이제스트(해싱된 메시지)를 HTTP 헤더로 전송할 수 있다.

GET /users/johndoe/financialrecords HTTP/1.1
Host: example.org
Authentication: hmac johndoe:[digest]

이제 서버는 사용자 "johndoe"가 자원에 접근을 시도한 것을 안다. 서버 역시 모든 정보를 가지고 있기 때문에 다이제스트를 생성할 수 있다. (서버에서 비밀번호의 실제값을 참조할 필요가 있기 때문에 비밀번호는 암호화 되지 않았다. 따라서 비밀번호를 "password"가 아닌 "secret"이라 부르겠다.).

누군가 이 대화를 듣고 있더라도, john이나 다른 사용자의 재정기록에 대한 POST 정보나 다른 URL에 대해 알 수 없다. 왜냐하면 다이제스트를 변경시키기 때문이다.

하지만, 다이제스트를 바꾸지 않는다면 외부인이 john의 재정기록에 대해 접근 할 수 있다. 이 때문에 실시간으로 정보를 전송하는 것이다.

digest = base64encode(hmac("sha256", "secret", "GET+/users/johndoe/financialrecords+20apr201312:59:24+123456"))

두가지 정보를 추가했다. 현재 데이터와 단 한번 사용하는 숫자이다.(nonce)

GET /users/johndoe/financialrecords HTTP/1.1
Host: example.org
Authentication: hmac johndoe:123456:[digest]
Date: 20 apr 2013 12:59:24

클라이언트 측에서 시간과 nonce를 보냈기 때문에, 서버는 다이제스트를 재구성할 수 있다. 만약 시간이 현재 서버 시간의 범위(예를 들자면 10분) 안에 들지 않는다면 서버는 메시지를 무시할 수 있다. (서버나 클라이언트의 시간이 잘못 된 경우도 존재한다. 제한시간 인증에서 이러한 문제는 빈번히 발생한다.)

nonce는 단 한 번 사용 되는 숫자이다. 만약 같은 자원에 다시 접근하길 원한다면, 반드시 이 숫자를 변경시켜 주어야 한다. 이는 우리가 매번 자원에 접근할 때마다, nonce가 다르다는 뜻이다. 이를 통해 replay공격으로 부터 방어할 수 있다. 각 요청은 단 한 번 요청되며 단 한 번 인증된다.

OAuth

hmac의 한가지 단점은 secret이 일반적인 형태라는 점이다. 한 번 john의 secret 유출이 되면, 모두가 그 secret을 통해 john의 계정에 접근할 수 있게 된다. 이러한 경우를 방지하는 방법이 시간제 토큰을 사용하는 것이다. 존은 서버에게 토큰과 secret을 요청한다. 그리고 이 토큰과 secret으로 보호된 자원에 접근할 수 있다.

OAuth는 시간제 토큰을 생성하는 하나의 방법론이다. OAuth는 인증구현에 사용 되는 일반적인 방법이지만 OAuth(1.1)은 초보자들이 도입하기에 설정이 다소 어렵다. 하지만 거의 모든 언어에 더 쉽게 적용할 수 있는 라이브러리가 존재한다.

OAuth2

OAuth2는 OAuth의 다음 버전이라고 볼 수 있지만, 기존 버전에 구조적으로 상당히 많이 바뀌었다. OAuth2는 인증기능 도입과 관리를 훨씬 쉽게 해주는 새로운 방법이다. 하지만, OAuth2는 아직 공식적으로 표준화되지 못했다. 그럼에도 불구하고 많은 사이트와 기관에서 현재 도안을 사용한다.