항해99 1주차 WIL(Json Web Token)

JWT(Json Web Token)

 

1. 설명

 

- JSON 웹 토큰(JSON Web Token, JWT, "jot”)은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준으로, 페이로드는 몇몇 클레임(claim) 표명(assert)을 처리하는 JSON을 보관하고 있다. 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명된다. 이를테면 서버는 "관리자로 로그인됨"이라는 클레임이 있는 토큰을 생성하여 이를 클라이언트에 제공할 수 있다. 그러면 클라이언트는 해당 토큰을 사용하여 관리자로 로그인됨을 증명한다. 이 토큰들은 한쪽 당사자의 비공개 키(일반적으로 서버의 비공개 키)에 의해 서명이 가능하며 이로써 해당 당사자는 최종적으로 토큰이 적법한지를 확인할 수 있다. 일부 적절하고 신뢰할만한 수단을 통해 다른 당사자가 상응하는 공개키를 소유하는 경우 이 경우 또한 토큰의 적법성 확인이 가능하다. 토큰은 크기가 작고 URL 안전으로 설계되어 있으며 특히 웹 브라우저 통합 인증(SSO) 컨텍스트에 유용하다. JWT 클레임은 아이덴티티 제공자와 서비스 제공자 간(또는 비즈니스 프로세스에 필요한 클레임)의 인가된 사용자의 아이덴티티를 전달하기 위해 보통 사용할 수 있다.

 

 

2. 구조

 

- 헤더

{
 "alg" : "HS256",
 "typ" : "JWT"
}

 

서명 생성을 위해 어느 알고리즘을 사용할지를 식별한다. HS256는 이 토큰이 HMAC-SHA256를 사용하여 서명됨을 의미한다. 일반적으로 쓰이는 암호화 알고리즘들은 SHA-2(HS256) 방식의 HMAC와 SHA-256(RS256) 방식의 RSA 서명이다. JWA(JSON 웹 알고리즘) RFC 7518은 인가 및 암호화를 위해 더 많은 것을 도입하고 있다.

 

- 페이로드

{
 "loggedInAs" : "admin",
 "iat" : 1422779638
}

일련의 클레임을 포함한다. JWT 사양은 토큰에 일반적으로 포함되는 표준 필드인 7개의 등록 클레임 이름(Registered Claim Names)을 정의한다. 토큰의 목적에 따라 사용자 지정 클레임 또한 일반적으로 포함된다.

다음 예는 표준 Issued At Time 클레임(iat)과 사용자 지정 클레임(loggedInAs)을 보여준다.

 

- 서명

HMAC-SHA256(
 secret,
 base64urlEncoding(header) + '.' +
 base64urlEncoding(payload)
)

토큰을 안전하게 확인한다. 서명은 Base64url 인코딩을 이용하여 헤더와 페이로드를 인코딩하고 이 둘을 점(.) 구분자로 함께 연결시킴으로써 계산된다. 해당 문자열은 그 뒤 헤더에 규정된 암호화 알고리즘(이번 경우에는 HMAC-SHA256)에 유입된다. Base64url 인코딩은 base64와 비슷하지만 각기 다른 영숫자를 사용하며 패딩(padding)은 제외한다.

 

2. API

1. 설명

 

API(application programming interface 애플리케이션 프로그래밍 인터페이스, 응용 프로그램 프로그래밍 인터페이스)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다. 이러한 연결이나 인터페이스를 빌드하거나 사용하는 방법을 기술하는 문서나 표준은 API 사양으로 부른다. 이 표준을 충족하는 컴퓨터 시스템은 API가 구현(implement)되었다거나 노출(expose)되었다고 말한다. API라는 용어는 사양이나 구현체를 의미할 수 있다.

컴퓨터와 인간을 연결시키는 사용자 인터페이스와 반대로, API는 컴퓨터나 소프트웨어를 서로 연결한다. 직접 사람(최종 사용자)에 의해 사용되도록 고안된 것이 아니며, 대신 소프트웨어에 이를 통합하고자 하는 컴퓨터 프로그래머가 사용하도록 고안되었다. API는 각기 다른 부분으로 구성되기도 하며 프로그래머가 사용할 수 있는 도구나 서비스의 역할을 한다. 이러한 부분들 중 하나를 사용하는 프로그램이나 프로그래머는 API의 해당 부분을 호출(call)한다고 말한다. API를 구성하는 호출들은 서브루틴, 메소드(method), 요청, 통신 엔드포인트라고도 부른다. API 사양은 이 호출들을 정의하며, 다시 말해 이들을 어떻게 사용하거나 구현하는지를 설명한다는 것을 의미한다.

API의 한 가지 목적은 시스템이 동작하는 방식에 관한 내부의 세세한 부분을 숨기는 것으로, 내부의 세세한 부분이 나중에 변경되더라도 프로그래머가 유용하게 사용할 수 있고 일정하게 관리할 수 있는 부분들만 노출시킨다. API는 특정 시스템용으로 커스텀하게 빌드될 수도 있고, 아니면 수많은 시스템 간 상호운용성을 허용하는, 공유가 되는 표준일 수도 있다.

API라는 용어는 웹 API를 의미하기도 하며, 이는 인터넷에 의해 병합된 컴퓨터들 간 통신을 허용한다. 프로그래밍 언어, 소프트웨어 라이브러리, 컴퓨터 운영 체제, 컴퓨터 하드웨어를 위한 API도 존재한다. API는 1940년대에 기원하였으나 이 용어는 1960년대, 70년대 들어서야 모습을 드러냈다.

 

2. 접근 방식

 

API의 접근 방식에는 크게 세 가지가 존재한다.

• Private API : API를 기업이나 연구 단체 등에서 사용하는 다양한 애플리케이션과 시스템의 통합을 위해 사용하는 것으로 단체 내부에서만 사용할 수 있도록 하는 것이다.
• Partner API : API를 특정 비즈니스 파트너와 공유하는 것으로, 공유받은 API를 품질 저하 없이 사용할 수 있으며 수익 창출을 목표로 사용하는 것이다.
• Public API : 모든 사람들에게 API를 제공하는 것으로, 개인이 API와 상호작용하는 프로그램을 무료로 개발할 수 있다. 다양한 아이디어를 통해 혁신적인 프로그램의 등장을 목표로 사용되고 있다.

3. 장점

 

앞서 API에 대하여 설명하면서 많은 장점들이 있었는데, 이 외에도 개발자들의 관점에서 크게 3가지의 장점이 있다.

1. 자동화가 용이 : API를 통해 사람이 직접 조작하지 않아도 관련 내용이 자동으로 생성되고 처리되어 워크플로우가 빨라질 수 있다.
2. 범위의 확장성 : API는 프로그램 사용 시 정보를 전달하는 기능이 있어 사용자의 환경에 맞춰서 전달할 수 있다. 또한 API에 직접 액세스 하지 않아도 콘텐츠가 자동적으로 생성 및 업로드되어 확장이 용이하다.
3. 적용력 : API는 변화 예측에도 큰 도움이 되기 때문에 API를 통해 데이터를 수집하고 전달하는 데 있어 유연한 서비스 환경을 구축할 수 있다.