2020.11.16

글로벌 칼럼 | 오쓰를 대체하는 GNAP에 참여하라

Andrew C. Oliver | InfoWorld
2012년이었다. 오쓰(OAuth) 2라는 개선된 보안 프로토콜이 웹을 휩쓸었고 사용자들은 보안 제공업체를 통해 웹 사이트에 손쉽게 로그인할 수 있었다. AWS의 코그니토(Cognito)부터 옥타(Okta)까지 많은 SSO(Single Sign-On) 시스템이 오쓰를 구현하고 있다. 오쓰를 통해 전혀 다른 웹 사이트나 애플리케이션에서 구글 또는 다른 제공업체를 통해 인증할 수 있다.
 
ⓒ Getty Images Bank

이는 마치 맥주 축제처럼 데스크를 찾아가 ID(그리고 약간의 돈)로 인증하면 토큰을 준다. 거기에서 각 맥주 천막으로 가서 토큰과 맥주를 바꾼다. 각 양조업자는 ID를 확인하거나 돈을 지불했는지 물어볼 필요가 없다. 이들은 토큰만 받고 맥주를 제공한다. 오쓰도 같은 방식으로 작동하지만 맥주가 아닌 웹 사이트라는 점이 다르다. 안타깝게도 오쓰는 2020년에 가장 필요한 맥주 축제다.

필자는 퓨전오스(FusionAuth)의 댄 무어와 오쓰에 관해 이야기를 나누었으며 GNAP(G는 묵음)이라는 대안을 제안했다. 보안은 매우 흥미로운 분야라는 느낌이 들게 하는 발음이다. GNAP은 오쓰의 한계 중 일부를 해결하고 새 기능을 제공한다.

오쓰를 강화하는 것이 아니라 대체하는 이유는 무엇일까? 오쓰는 브라우저를 중심으로 개발됐다. 요청하는 사람이 HTTP 재전송을 처리할 수 있다고 가정한다. 이런 웹 브라우저 중심성은 모바일 앱 또는 기타 ‘사물인터넷’의 ‘사물’에 장애물로 작용한다. 또한 오쓰 당사자들은 2007년도처럼 JSON이 아니라 서식 파라미터를 게시하도록 요구한다.

오쓰의 사양이 모호한 곳도 있었으며, 2012년 이후로 세상이 바뀌었다. 많은 RFC(Request for Comments)와 BCP(Business Continuity Plan)가 존재하며, 이것들은 기본적으로 추가적인 기능, 향상된 보안, 전반적인 호환성을 위해 구현해야 하는 부가기능 사양이다. 

오쓰 2.1은 이런 부가기능 중 일부를 더욱 일관성 있는 단일 사양으로 통합하려 하고 있다. 오쓰 2.1은 GNAP과 달리 점진적인 릴리즈에 불과하며 사양 스택을 단일 사양으로 통합한다는 점 외에는 새로운 큰 변화가 없다.

GNAP 사양은 아직 초기 단계이다. GNAP의 개발자들은 오쓰 2.1보다 한 차원 더 발전해 프로토콜 자체의 속성을 바꿀 계획이다. HTTP 파라미터를 사용하는 대신 JSON을 사용할 수 있다. 애플리케이션 엔드포인트를 검색할 수 있다. 재전송(또는 이와 관련된 다양한 해킹)을 지원할 필요가 없다. 무어는 이런 변화를 좀 더 경쾌한 ‘개발자 인체공학(developer ergonomics)’이라고 표현한다.

GNAP의 핵심 목표는 리소스를 요청하는 사람(requests the resources, RQ)과 리소스를 소유한 사람(owns the resources, RO)을 구분하는 것이다.
 
ⓒ IETF

또한 GNAP은 다음과 같은 새로운 보안 기능을 지원할 것이다.
 
  • 비동기식(Asynchronous)애플리케이션 URL 런치(Application URL Launch): 다른 인증 경로를 통해 클라이언트는 재전송 없이 인증할 수 있다. 또한 GNAP은 애플리케이션이 리소스 서버와 인증 서버가 직접 액세스할 수 없는 서드파티 리소스를 인증할 수 있도록 허용한다.
  • 연속 요청(Request Continuation): 이를 통해 클라이언트는 인증 과정 중 재전송 또는 기타 인증 세부사항을 협상할 수 있다. 또한 클라이언트는 추가적인 권한이나 액세스 토큰을 인증할 수 있다.
  • 멀티 액세스 토큰(Multiple Access Tokens): 클라이언트는 사용자와 관리자 등 여러 리소스를 한 번에 인증할 수 있다.
  • 발신자 제한 토큰(Sender Constraint Tokens): 오쓰 2에는 이 기능을 위한 DPOPMTLS라는 부가 기능이 있지만 GNAP은 이를 프로토콜에 직접 내장한다. 맥주 축제의 예로 되돌아 가보자. 판매자에게 토큰을 제공하면서 그들의 귀에 대고 비밀번호를 속삭여야 한다면 어떨까? 우리가 토큰을 떨어뜨리면(또는 빼앗기면) 전달자에게 비밀번호가 없기 때문에 상관없을 것이다.
  • GNAP 때문에 커베로스(Kerberos)의 유령이 소리를 지르게 된다.

괜찮아 보이는가? 오늘 당장 GNAP을 사용하기 시작할 수 있을까? 협업에 관심이 있다면 깃허브에서 기존에 제안된 프로토타입 중 하나를 포킹(Forking)할 수 있다. 무어에 따르면, 개발자들은 GNAP을 2022년에 공개할 계획이어서 아직도 한참 기다려야 한다. 하지만 GNAP 작업 그룹은 협업자를 찾고 있으며, 다른 개발자의 피드백을 원하며, 전문지식을 제공할 수 있다. 세상의 모든 것을 고칠 수는 없겠지만 최소한 오쓰를 고치도록 도울 수 있을 것이다. editor@itworld.co.kr  


2020.11.16

글로벌 칼럼 | 오쓰를 대체하는 GNAP에 참여하라

Andrew C. Oliver | InfoWorld
2012년이었다. 오쓰(OAuth) 2라는 개선된 보안 프로토콜이 웹을 휩쓸었고 사용자들은 보안 제공업체를 통해 웹 사이트에 손쉽게 로그인할 수 있었다. AWS의 코그니토(Cognito)부터 옥타(Okta)까지 많은 SSO(Single Sign-On) 시스템이 오쓰를 구현하고 있다. 오쓰를 통해 전혀 다른 웹 사이트나 애플리케이션에서 구글 또는 다른 제공업체를 통해 인증할 수 있다.
 
ⓒ Getty Images Bank

이는 마치 맥주 축제처럼 데스크를 찾아가 ID(그리고 약간의 돈)로 인증하면 토큰을 준다. 거기에서 각 맥주 천막으로 가서 토큰과 맥주를 바꾼다. 각 양조업자는 ID를 확인하거나 돈을 지불했는지 물어볼 필요가 없다. 이들은 토큰만 받고 맥주를 제공한다. 오쓰도 같은 방식으로 작동하지만 맥주가 아닌 웹 사이트라는 점이 다르다. 안타깝게도 오쓰는 2020년에 가장 필요한 맥주 축제다.

필자는 퓨전오스(FusionAuth)의 댄 무어와 오쓰에 관해 이야기를 나누었으며 GNAP(G는 묵음)이라는 대안을 제안했다. 보안은 매우 흥미로운 분야라는 느낌이 들게 하는 발음이다. GNAP은 오쓰의 한계 중 일부를 해결하고 새 기능을 제공한다.

오쓰를 강화하는 것이 아니라 대체하는 이유는 무엇일까? 오쓰는 브라우저를 중심으로 개발됐다. 요청하는 사람이 HTTP 재전송을 처리할 수 있다고 가정한다. 이런 웹 브라우저 중심성은 모바일 앱 또는 기타 ‘사물인터넷’의 ‘사물’에 장애물로 작용한다. 또한 오쓰 당사자들은 2007년도처럼 JSON이 아니라 서식 파라미터를 게시하도록 요구한다.

오쓰의 사양이 모호한 곳도 있었으며, 2012년 이후로 세상이 바뀌었다. 많은 RFC(Request for Comments)와 BCP(Business Continuity Plan)가 존재하며, 이것들은 기본적으로 추가적인 기능, 향상된 보안, 전반적인 호환성을 위해 구현해야 하는 부가기능 사양이다. 

오쓰 2.1은 이런 부가기능 중 일부를 더욱 일관성 있는 단일 사양으로 통합하려 하고 있다. 오쓰 2.1은 GNAP과 달리 점진적인 릴리즈에 불과하며 사양 스택을 단일 사양으로 통합한다는 점 외에는 새로운 큰 변화가 없다.

GNAP 사양은 아직 초기 단계이다. GNAP의 개발자들은 오쓰 2.1보다 한 차원 더 발전해 프로토콜 자체의 속성을 바꿀 계획이다. HTTP 파라미터를 사용하는 대신 JSON을 사용할 수 있다. 애플리케이션 엔드포인트를 검색할 수 있다. 재전송(또는 이와 관련된 다양한 해킹)을 지원할 필요가 없다. 무어는 이런 변화를 좀 더 경쾌한 ‘개발자 인체공학(developer ergonomics)’이라고 표현한다.

GNAP의 핵심 목표는 리소스를 요청하는 사람(requests the resources, RQ)과 리소스를 소유한 사람(owns the resources, RO)을 구분하는 것이다.
 
ⓒ IETF

또한 GNAP은 다음과 같은 새로운 보안 기능을 지원할 것이다.
 
  • 비동기식(Asynchronous)애플리케이션 URL 런치(Application URL Launch): 다른 인증 경로를 통해 클라이언트는 재전송 없이 인증할 수 있다. 또한 GNAP은 애플리케이션이 리소스 서버와 인증 서버가 직접 액세스할 수 없는 서드파티 리소스를 인증할 수 있도록 허용한다.
  • 연속 요청(Request Continuation): 이를 통해 클라이언트는 인증 과정 중 재전송 또는 기타 인증 세부사항을 협상할 수 있다. 또한 클라이언트는 추가적인 권한이나 액세스 토큰을 인증할 수 있다.
  • 멀티 액세스 토큰(Multiple Access Tokens): 클라이언트는 사용자와 관리자 등 여러 리소스를 한 번에 인증할 수 있다.
  • 발신자 제한 토큰(Sender Constraint Tokens): 오쓰 2에는 이 기능을 위한 DPOPMTLS라는 부가 기능이 있지만 GNAP은 이를 프로토콜에 직접 내장한다. 맥주 축제의 예로 되돌아 가보자. 판매자에게 토큰을 제공하면서 그들의 귀에 대고 비밀번호를 속삭여야 한다면 어떨까? 우리가 토큰을 떨어뜨리면(또는 빼앗기면) 전달자에게 비밀번호가 없기 때문에 상관없을 것이다.
  • GNAP 때문에 커베로스(Kerberos)의 유령이 소리를 지르게 된다.

괜찮아 보이는가? 오늘 당장 GNAP을 사용하기 시작할 수 있을까? 협업에 관심이 있다면 깃허브에서 기존에 제안된 프로토타입 중 하나를 포킹(Forking)할 수 있다. 무어에 따르면, 개발자들은 GNAP을 2022년에 공개할 계획이어서 아직도 한참 기다려야 한다. 하지만 GNAP 작업 그룹은 협업자를 찾고 있으며, 다른 개발자의 피드백을 원하며, 전문지식을 제공할 수 있다. 세상의 모든 것을 고칠 수는 없겠지만 최소한 오쓰를 고치도록 도울 수 있을 것이다. editor@itworld.co.kr  


X