week 8 leekynnghee - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

jwt란 무엇이며, 구성은 어떻게 되어 있고, oAuth(open Authorization)와 차이는?

모바일 앱으로 변화하면서 브라우저가 없기 때문에 세션, 쿠키 관리를 하지못함

JWT란?

JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다

클레임? Self-Contained 방식?은 무엇이지? 아래에서 좀더 자세히 알아보겠습니다.

JWT 사용법?

애플리케이션이 실행될 때, JWT를 static 변수와 로컬 스토리지에 저장하게 된다.
static 변수에 저장되는 이유는 HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아서 보내야 하는데, 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문이다.
클라이언트에서 JWT를 포함해 요청을 보내면 서버는 허가된 JWT인지를 검사한다.
또한 로그아웃을 할 경우 로컬 스토리지에 저장된 JWT 데이터를 제거한다.

(실제 서비스의 경우에는 로그아웃 시, 사용했던 토큰을 blacklist라는 DB 테이블에 넣어 해당 토큰의 접근을 막는 작업을 해주어야 한다.)

JWT 특징

JSON 웹 토큰은 페이로드에 몇 가지 클레임을 제기하는 JSON이 포함 된 선택적 서명 및 / 또는 선택적 암호화를 사용하여 데이터를 작성하기위한 인터넷 표준입니다.
토큰은 개인 비밀 또는 공개 / 개인 키를 사용하여 서명됩니다.

일반 토큰 기반의 인증과 클레임(Claim) 토큰 기반 인증

일반 토큰 기반은 과거에 많이 사용하던 방식이다. 주로 의미가 없는 문자열(Random string) 기반으로 구성되어 있으며 아래와 같이 표현이 된다.

{
    "code": 0,
    "msg": null,
    "response":{
        "token": "a9ace025c90c0da2161075da6ddd3492a2fca776",
        "now": 1512446940,
        "expired_at": 1512448740
    }
}

일반 토큰을 사용할 경우 문제점은?

이런 일반 토큰은 단순한 문자열이기 때문에 정보를 담거나 할 수 없다. 크게 보자면 아래와 같은 문제점을 가지고 있다.

발급된 토큰에 대해서 만료를 시킬 수단이 없다.
발급된 토큰을 검사하거나 처리할 때마다 DB에 접근하여 검사할 경우 부담이 생긴다.
사용자 로그아웃 등으로 인한 토큰을 관리할 수 있는 방법이 없다.

이와 같은 문제를 어느정도 해결할 수 있는 것이 클레임(Claim) 기반 토큰 방식이다.

클레임(Claim)이란 사용자 정보나 데이터 속성 등을 의미한다.

그래서 클레임 토큰이라 하면 토큰 안에 저런 정보를 담고 있는 토큰이라 생각하면 된다.

예를 들면 아래와 같이 정보를 담고 있는 것을 클레임 기반이라 할 수 있다.

{
  "id":"mhlab",
  "role":["admin","hr"],
  "company":"hexlant"
}

이런 클레임을 기반한 토큰 중 가장 대표적인 것이 바로 JWT다.

What is JWT?

JWT(Json Web Token)은 위에서 이야기 한 클레임 기반 토큰이며, 이름에서 알 수 있는 것처럼 JSON을 이용한 토큰이고 웹 표준(RFC 7519)를 구현한 것이다.
자세한 내용은 JWT 공식페이지에서 확인 가능하다.

구조와 생성

HEADER.PAYLOAD.SIGNATURE

헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분을 점(.)으로 구분하는 구조다.

Header

JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64 URL-Safe 인코딩된 문자열이다.
헤더(Header)는 JWT를 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다.
참고로 alg는 서명 시 사용하는 알고리즘이고, kid는 서명 시 사용하는 키(Public/Private Key)를 식별하는 값이다.

{
    "alg": "ES256",
    "kid": "Key ID"
}

위와 같은 JSON 객체를 문자열로 직렬화하고 UTF-8과 Base64 URL-Safe로 인코딩하면 다음과 같이 헤더를 생성할 수 있다.

Base64URLSafe(UTF-8('{"alg": "ES256","kid": "Key ID"}')) -> eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9

Payload

JWT의 내용이다. 페이로드(Payload)에 있는 속성들을 클레임 셋(Claim Set)이라 부른다.
클레임 셋은 JWT에 대한 내용(토큰 생성자(클라이언트)의 정보, 생성 일시 등)이나 클라이언트와 서버 간 주고 받기로 한 값들로 구성된다.

{
    "iss": "jinho.shin",
    "iat": "1586364327"
}

위와 같은 JSON 객체를 문자열로 직렬화하고 Base64 URL-Safe로 인코딩하면 다음과 같이 페이로드를 생성할 수 있다.

Base64URLSafe('{"iss": "jinho.shin","iat": "1586364327"}') -> eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ

Signature

점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다.

Base64URLSafe(Sign('ES256', '${PRIVATE_KEY}',
'eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ'))) ->
MEQCIBSOVBBsCeZ_8vHulOvspJVFU3GADhyCHyzMiBFVyS3qAiB7Tm_MEXi2kLusOBpanIrcs2NVq24uuVDgH71M_fIQGg

JWT

점을 구분자로 해서 헤더, 페이로드, 서명을 합치면 JWT가 완성된다.

eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLn
NoaW4ifQ.eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRC9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6Imp
pbmhvLnNoaW4ifQ.MEQCIBSOVBBsCeZ_8vHulOvspJVFU3GADhyCHyzMiBFVyS3qAiB7Tm_ME
Xi2kLusOBpanIrcs2NVq24uuVDgH71M_fIQGg

이렇게 완성된 JWT는 헤더의 alg, kid 속성과 공개 키를 이용해 검증할 수 있다.
서명 검증이 성공하면 JWT의 모든 내용을 신뢰할 수 있게되고, 페이로드의 값으로 접근 제어나 원하는 처리를 할 수 있게된다.

JWT를 통한 Client-Server간 인증 과정

Client에서 로그인을 하면 Server에서 로그인 확인 후 secret key를 통해 Access token을 발급하여 클라이언트에 JWT를 반환해준다.
그 후 JWT를 클라이언트에서 보관하다 서버에 요청을 할 때 마다 JWT를 같이 Request Header에 전달해주면
서버에서 클라이언트가 준 JWT의 서명을 체크하고 JWT에서 사용자 정보를 확인한 뒤
올바를 경우 클라이언트의 Request에 맞는 Response를 반환하고, 맞지 않을 경우 그에 따른 처리를 한다.

JWT 장점

사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다.

OAuth2 를 왜 사용하나?

구글이나 페이스북 국내에서는 네이버나 카카오 등 로그인하기 기능을 이용하면 구현의 난이도를 낮추 수 있고 사용자 인증을 간소화할 수 있다.
또한 대형 보안 사고의 위험을 전문 인력을 갖추고 있는 거대 기업들에게 넘길 수 있다.
무엇보다 이들 기업의 API를 다루기 위해서는 인증이 필요한데 오늘날 대부분의 기업들이 OAuth를 인증으로 채택하고 있다.

OAuth 란 무엇이며 Protocol flow은?

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준(IEEE, ISOC, W3C, IETF 및 IAB 공동 정의)이다

OAuth is an open standard for access delegation commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

Open Authorization이 나오게 된 배경

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조이다.
기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다.
OAuth는 이렇게 제각각인 인증방식을 표준화한 인증 방식이다.
OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요 없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 합니다.
Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(ex Facebook, Google 로그인 url)을 보냅니다.
Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 Authorization Grant를 url에 실어 Client에게 보냅니다.
Client는 해당 권한증서(Authorization Grant)를 Authorization Server에 보냅니다.
Authorization Server는 권한증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해줍니다.
Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘깁니다.
Resource Owner(사용자)가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청합니다.
Resource Server는 Access Token이 유효한지 확인 후, Client에게 자원을 보냅니다.
만일 Access Token이 만료됐거나 위조되었다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급 받습니다.
그 후 다시 Resource Server에 자원을 요청합니다.
만일 Refresh token도 만료되었을 경우, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야합니다. (이는 다시 사용자가 다시 로그인 하라는 말입니다.)

OAuth2 승인 방식의 종류

Authorization Code Grant Type : 권한 부여 코드 승인 타입

클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용됩니다.
리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식입니다.

Implicit Grant Type : 암시적 승인

권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식입니다.

Resource Owner Password Credentials Grant Type : 리소스 소유자 암호 자격 증명 타입

클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 때입니다.

Client Credentials Grant Type : 클라이언트 자격 증명 타입

클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식입니다.

[참고]

http://tools.ietf.org/html/rfc6749

[읽어보기]

OAuth2 4가지 방식 상세 내용

https://okky.kr/article/420615

[실습]

https://okky.kr/article/365347

온프로미스 환경과 클라우드 환경의 차이 및 장단점

서버리스 애플리케이션을 구축하면 인프라 관리 및 운영 대신 애플리케이션 코드에 집중할 수 있습니다.
AWS에서 모든 것을 대신 처리하므로 서버 프로비저닝이나 구성에 대해 고민할 필요가 없습니다. 따라서 인프라 관리 부담이 줄어들고 제품 출시를 앞당길 수 있습니다.
서버리스 애플리케이션 구축에 따른 4가지 주요 이점은 다음과 같습니다.

서버 관리 불필요

서버를 프로비저닝하거나 유지 관리할 필요가 없습니다. 설치, 유지 또는 관리할 소프트웨어나 런타임이 없습니다.

유연한 확장성

애플리케이션은 자동으로 확장될 수 있고, 개별 서버 단위가 아니라 사용 단위(예: 처리량, 메모리)를 설정/해제하여 용량을 조정할 수도 있습니다.

고가용성

서버리스 애플리케이션은 내장된 가용성과 내결함성을 갖추고 있습니다. 애플리케이션을 실행하는 서비스에서 기본적으로 이를 제공하므로 이러한 기능을 설계할 필요가 없습니다.

유휴 용량 없음

유휴 용량에 대한 비용을 지불할 필요가 없습니다.
컴퓨팅이나 스토리지 등의 용량을 사전 프로비저닝하거나 오버 프로비저닝할 필요가 없습니다. 예를 들어 코드가 실행되지 않을 때는 비용이 부과되지 않습니다.