oauth2로 바꾼다고 security가 더 강화되는 게 아닙니다. api key를 header를 통해 전달하도록 하면, api key와 oauth2는 security 보호 수준이 같아요.
authentication/authorization 방법의 security 보호 수준을 확인하려면 security-at-rest (저장소에서의 api key 보호 수준), security-in-transit (송신 중 api key 보호 수준) 두 가지를 보면 되는데요.
security-in-transit을 먼저 보면요.
oauth2가 제공하는 프로토콜을 따라가면 마지막에는 데이터 retrieval을 위해 api key와 같은 방식을 사용합니다. 결국 api key (oauth2 용어로는 access token)를 헤더를 통해 제공하고 http post 호출을 하는 겁니다. 그냥 둘 다 SSL/TLS에 의지하는 것이므로 보호 수준이 동일합니다. 어떤 추가 encryption 같은 게 있지 않아요.
oauth2를 그럼 왜 쓰느냐 하면 패스워드를 3rd party에게 제공하지 않으면서 3rd party에게 권한을 위임을 할 수 있는 표준이기 때문이고요. 그러면서 어떤 권한을 위임할 것인지도 resource owner가 정할 수 있는 (scope라 불리는) 방법을 제공합니다.
지금 원글이 말씀하시는 것으로 볼 때, 권한은 이미 정해져 있어서 oauth2가 제공하는 scope (여러 권한 가운데 허락할 권한을 고르도록 하는 기능)가 필요한 상황이 아니고, 데이터의 retriever와 consumer가 동일한 상황인 것 같기 때문에 위임이 필요한 상황도 아니죠. 그럼 oauth2를 쓰는 건 보안 수준을 높이는 것도 아니면서 불필요한 복잡도를 추가하는 것이죠. api key가 적당한 상황입니다.
oauth2로 가야하는 조건은, 그 마케팅 회사가 직접 자기네 고유의 서비스를 제공하면서 그 서비스가 원글 회사의 데이터를 사용해야 하는 경우입니다. 그때는 oauth2가 최선이고 적당한 서비스입니다.
security-at-rest를 보면요.
큰 오류는 아니지만, 위엣분 답장을 약간 수정하고 싶네요. 일반적으로는 로그인할 때마다 새 access token을 (api key에 해당하는) 만들지는 않습니다. 한번 만든 토큰을 꽤 오랜 기간 재사용합니다 (그 기간은 token issuer가 지정하는데, 예를 들면 1일, 1주일, 1달, 6개월 같은 식입니다. 게다가 access token을 3rd party에게 발행할 때 access token을 자동 갱신할 수 있는 권한까지 함께 3rd party에게 줍니다.
예를 들어 online diagramming 서비스를 제공하는 회사가 google drive에 저장하고 싶다고 하면, google은 access token과 access token을 갱신할 수 있는 권한 두 가지를 한꺼번에 online diagramming 서비스 회사에게 주죠. 물론 읽기만 허락할 것인지, 읽고 쓰기를 모두 허락할 것인지 (즉 scope 지정)에 대해, 사용자가 허락 버튼을 눌러줘야 하고요. 그런데 일단 허락 버튼을 누르고 나면 그 다음부터는 다시 허락 버튼을 누르지 않아도 되는 걸 볼 수 있죠? 그 이유는 online diagramming 서비스 회사가 access token과 그 access token을 갱신할 수 있는 권한 (refresh token이라 불리는)을 함께 저장하고 있기 때문입니다.
여기서 refresh token은 access token을 갱신하기 위한 패스워드의 역할을 하기 때문에 refresh key를 탈취당하면 api key, access token을 탈취당하는 것과 같습니다. 즉 저장된 api key를 노출되지 않게 잘 관리하는 문제와 refresh token을 잘 관리하는 문제는 security 보호 수준에서 볼 때 똑같아요. oauth2가 online protocol만 다루기 때문에, 저장소에서 access token, refresh token이 보호되느냐 안 되느냐 하는 걸 oauth2에게 따질 문제는 아닙니다만.
종합적으로 판단하는 기준은, oauth2가 제공하는 위임 기능이 필요한가? 3rd party에게 허락할 권한의 종류가 여러 개이고 사용자에게 그 중 하나를 고르도록 허용할 것인가 (즉 scope가 필요한가)? 에 대답이 하나라도 Yes 이면 oauth2로 갈 이유가 됩니다.
access token (or api key) 발행 후 ip whitelisting 하기가 지금 원글의 요구 사항을 구현하는 데 적당하다는 위엣분 말씀에 저도 의견을 같이합니다.
