IT의 중심에서

중년 개발자가 살아 가는 IT 현장 이야기

API key, API 인증과 권한관리

Apigee Webinar “10가지 API 로드맵 고려사항” 중 세번째 글입니다.

API 보안관리에 대한 다소 “기초적”인 글입니다. API개발경험이 많은 회사도 API를 Open할 때,  어떤 기술구조를 가지고 가야 “효율적”인지 잘 모릅니다.

사용량이 많을 걸 전제로 하기 때문에 복잡한 기술구조를 쓰게 되는데, 기술구조가 복잡하면 매번 요구사항이 바뀔 때마다 대응하기가 쉽지 않습니다. 특히 보안문제가 얽히면 더 그렇습니다.

복잡한 이야기들은 차차 할 기회가 있을 것 같습니다. 우선 Apigee가 이야기한 내용들을 간단히 정리해 보았습니다.

참고로, Apigee는 실리콘밸리의 OpenAPI  대행업체로 2016년 구글에 인수되었습니다. 고유자산은 AWS에서 운영되는 API 플랫폼입니다. 처음에는 스타트업을 상대하다가 나중에는 일반 기업시장으로 돌아섰습니다.

아래 웨비나를 하던 당시는 약 200개가 넘는 회사의 API를 운영대행하고 있었습니다. 그래서 아래 내용은 API 전략을 어떻게 수행하는지를 고객에게 설명하는 자료입니다. 청중은 API 를 거의 이해하지 못하는 사람들 대상이었니다. (update.18.04.18)


※ 원문 : Do you need API keys? API Identity vs. Authorization

우리는 그동안 제대로 된 Open API를 운영하는 업체들을 거의 만나지 못했다. 제대로 된 API라면 최소한 아래 세가지를 모두 대응하고 있어야 한다.

  • Identity – 식별.  API 요청을 하는 사람이 누구인지?
  • Authentication – 인증. 그 사람들이 정말 접속을 허락한 그 사람들인지?
  • Authorization – 권한. 그 사람들이 그 일을 할 수 있도록 허락은 맞았는지?


하지만, 항상 모든 경우가 3가지를 다 필요로 하지 않는다. 어떤 API 는 단지 Identity만 필요하고, 인증, 권한은 필요없을 수도 있다.

API Identity vs. Authentication – 구글맵과 트위터

구글지도를 보자. Open API 를 제공한다. 그래서 구글은 누가 접속하는지 알고 싶어 한다. 하지만, 어떤 주소를 검색하는지는 굳이 알고 싶지 않다. 그래서 그들은 Identity만 확인한다.

그래서 구글맵은 개발자들에게 API key 를 제공한다. 하지만, 인증 및 권한관리는 하지 않는다. 조회 중심의 서비스라 다른 사람의 API key를 사용해도 심각한 보안 문제가 생기지 않는다.

대신 API key를 이렇게 사용한다.  요청자별로 API request 수에 제한을 건다. 즉, Service Volumn(트래픽 수용량)을 통제하기 위해 Identity 정책을 실행하고 있다.

트위터 API 를 보자. 트윗을 검색할 수 있도록 오픈되어 있다. 그러나 다른 작업들은 권한Authorization이 걸려 있다. 그래서, 트위터는 사용자 암호 인증과 OAuth 인증을 둘 다 제공한다. 트위터는 코드안에 인증코드를 가지고 있다. 그래서 당신은 그들의 패스워드나 계정에 대한 OAuth 없이 다른 사람 이름으로 트윗을 올릴 수 없다.  이것이 Identity,  Authentification, Authorization을 보여주는 대표적인 사례이다.

The “API Key” – do you need one?

API key 는 야후나 구글 API 처럼 웹서비스에서 시작되었다. 개발자들은 암호를가지고 사용자를 인증하는 복잡한 과정없이 Identity를 확인하고 싶어 했다. (해킹방지를 위해 암호를 또 암호화해야 했기 때문이다.)  그래서 API key 를 만들었다. 형태는 UUID나 unique string 이기도 했었다.

API key 에 매우 민감한 데이터의 접근권한만 안 준다면, 보안에도 그다지 민감하지 않았다. 그러다 보니 외부개발자들이 좀 더 쉽게 API 를 호출할 수 있게 되었다.

즉, API Key는 누가 우리 시스템에 접근하는지 그리고, 얼마나 API를 사용하는지 식별할 수 있는 가장 편리한 방법이 되었다. 심지어, API Key 별로 호출량을 통제할 수도 있다.

Usernames and Passwords – again, see Twitter

훨씬 더 민감한 데이터라면 오히려 간단하다. 만일 사용자가 API key를 안전하게 관리하는지 믿을 수 없다면, 더 보안을 강화해야 한다. 대체수단은 유저아이디와 암호인증이다. 대부분의 secure 페이지 권한관리랑 같은 거다.

일반적으로 http basic 인증을 사용하는 것이 가장 쉽다. 이 기술의 잇점은 거의 모든 클라이언트와 서버가 그 방식을 지원한다는 것이다. 특별한 프로세스를 만들 필요가 없다. 개발자가 암호관리에 주의를 충분히 조심한다면 말이다.

유저가 트위터 클라이언트를 시작할 때마다, 유저아이디와 암호를 물으면 된다. (암호가 또 암호화되어 있을 수 있다.) 그래서, 트위터는 API 도 유저아이디와 암호를 가지도록 되어 있다. 유저아이디와 암호는 어플간의 커뮤니케이션에 더 적합하기도 하다.

하지만, 암호를 저장할 땐 신중해야 한다.  만일 프로그램에 이용하려면 암호는 어디에 어떻게 저장하고 꺼내와야 할까? 만일 DB 를 사용하고 있다면, 비교적 간단하다. 왜냐하면, DB 도 유저와 암호를 알아야 접근할 수 있기 때문이다. 하지만, 그렇지 않다면 서버플랫폼은 상대적으로 안전하게 암호를 저장할 수 있는 ‘credential mapper’를 가지고 있어야 한다.

Session-based Authentication – cumbersome with RESTful APIs

많은 API 들이 세션 기반의 인증을 제공할 수있다. 이 구조에서는, 서버는 처음에 login method를 호출한다. 그리고, 유저아이디와 암호를 입력받고, 고유의 세션키를 리턴한다.

그러면, 개발자는 각 request 마다 세션키를 포함해서 기능을 호출한다. 그리고, 일이 모두 끄나면 logout 을 호출한다.

이 방법은 처음에 Session key를 발급받고 맨 나중에 Session Key를 Expire시키기 위한 한 쌍의 API 가 필요하다. 일단 Session key를 발급받으면, 트랜잭션이 끝날 때까지 모든 서버 호출은 Session Key를 기반으로 수행된다.

이런 종류의 인증은 웹사이트에 매우 잘 사용된다.  왜냐하면, 사용자들은 특정 사이트에 접속하면, 습관적으로 log in 하고 일이 끝나면 log out 하기 때문이다.

하지만, Session 기반의 인증은 API 와 관련되어질 때 좀 복잡해진다. 즉, API client가 계속 Login, Logout 상태를 관리해야 한다는 뜻이다. 만일 그러기 힘든 client 라면 API를 이용할 수 없게 된다.

Session 기반이 인증은 개발자를 좀 복잡하게 만든다. API client 를 만들 때 최소한 3 개의 http request를 해야 한다는 뜻이다. (login, 필요한거, logout)

Two-Way SSL, X.509, SAML, WS-Security…

만일 http 가 아닌 다른 걸 써야 한다면, SAML, X.509 인증, 양방향 SSL 등을 고려해 볼 수 있다.  특정 client 에 WS-Security 를 준수하는 public key를 배포할 수도 있다. SOAP 도 이용할 수 있다. 어쨌든 선택은 다양해진다.

이런 API 는 원칙적으로 기업형 고객들이 선호한다. 특히 대형 IT 기업들. 그들은 X.509인증서나, 단순한 아이디/암호 인증보다 더 복잡한 형태의 SAML류를 고려하기도 한다.

그러다보니, 큰 기업들은 SOAP 표준 API 를 저 많이 사용하기도 한다. 왜냐하면, 복잡한 것들 중에서는 비교적 쉽게 WSDL 파일을 import 하고, 몇 분만에 API client 를 만들 수 있기 때문이다.

Know your audience.

만일 기업고객이 SOAP이나 WSDL 의 팬이라면, SAML 이나 WS-security specifications 과 같은 SOAP 틱한 인증을 고민해보라.  이 말을 이해하지 못한다면, 아직 이런 고객을 만나지 못했을 것이다.

SSL

대부분의 인증 파라미터는 불필요하다. 또는 위험할 수도 있다. “SSL이 없다면 말이다.”
예를 들어 http basic 인증에서 API 는 client 가 사용하는 암호를 읽어야 한다. 그래서 암호를  base64로 인코딩한다. 하지만, 인코딩은 암호화가 아니다. 디코딩이 너무 쉽기 때문이다.

가장 쉬운 방법은 client와 server 사이에 전송되는 모든 것을 암호화하는 것이다. SSL을 사용하면 된다. 이것은 일반적으로 사용하기 쉽고, 생각만큼 성능 감소가 많지 않다. (Apigee 의 경우, throughput이 10~15% 정도 감소했다.)

OAuth와 같은 security 구조들은 도청 보안 등을 고려해서 만들어졌다. 예를 들면, OAuth 는 각 request 에 대해 ‘일회용 키’를 포함한다. 그래서 하나의 request 상에서 OAuth 토큰을 가로채더라도 다음에는 그것을 사용할 수 없게 된다. 물론 request 상에서 민감한 정보들에 대해서도 그렇다.

일반적으로, 만일 당신의 API 가 SSL 을 사용하지 않는다면, 잠재적으로는 API 가 하는 모든 일이 노출될 수 있다.

So Many Authentication Schemes – What Should You Use?

OAuth, OpenID, SAML, HTTP authentication, WS-Security, and the basic API key – 수많은 API 많큼 수만은 인증 scheme들이 있다. 언제 무엇을 사용할 것인가? 잘 모르겠다면 우리에게 연락을 해라.

…. 크~ Webinar 다 보니까, 기승전 영업이네요.

※ 2018.4.18. 기존 번역이 허접해서 전체적으로 문맥을 다듬었습니다.

API key, API 인증과 권한관리”에 대한 6개의 댓글

  1. s_jeho
    2018년 12월 14일

    관련 내용 서치하다가 찾았습니다. 트위터에서만 뵙다가 블로그에서 뵈니 새롭네요..ㅎㅎ 개요를 잘 표현한 글이라서 어느 방향으로 파봐야 할지 많이 도움되었습니다. 시간내서 번역해주셔서 정말 감사드립니다. 번역만큼 다른분들에게 파급을 주는 활동도 많지 않을것 같습니다. 좋은 글 감사드립니다.

    • subokim
      2018년 12월 14일

      아닙니다. 발번역인데 좋게 봐주셔서 감사합니다.

  2. 익명
    2018년 5월 27일

    도움 많이 되었습니다. 그런데 원문이 보이지 않네요 ㅠ

    • subokim
      2018년 5월 28일

      네. 업데이트 해보려고 저도 열심히 찾아보았는데, 실패했습니다. 찾아지는대로 다시 업데이트 하겠습니다.

  3. 익명
    2018년 4월 18일

    쓰레기 내용이네요

    • subokim
      2018년 4월 18일

      오오. 강한 자신감을 가지신 분이군요.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

정보

이 엔트리는 2012년 3월 5일에 님이 API와 기술에 게시하였으며 , , , , 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: