아스

인프런 강의를 들으면서 내가 이해한 내용들과 궁금한 점들을 정리해 보았다.

(중간중간 이해되는 내용이 많아질 경우 계속 내용이 추가될 예정이다)

✅ 웹 어플리케이션 서버(WAS)와 웹 서버(WS)의 차이점은 무엇일까

WS는 정적인 컨텐츠에 대한 요청을 처리하며, WAS는 웹 어플리케이션 로직을 통해 동적인 요청을 처리할 수 있다는 점이 가장 큰 차이이다. 그러나 요즘은 WS도 설정하기에 따라 꼭 정적 컨텐츠에 대한 요청만 처리하는 것은 아니라고 해서... 무 자르듯이 아주 정교하게 구분하기는 어렵다고 한다. 또한 예전 멘토링에서 말씀하신 것처럼 WAS 안에 WS가 있는 구조라고 한다. WS는 예를 들면 apache, nginx 등이 있고, WAS는 사용하는 프레임워크 별로 다양하다. 가령 django WAS, tomcat 등이 있다. 

✅ 그러면 WAS만 사용하면 되는 게 아닌가? 굳이 정적인 요청만 처리할 수 있는 WS는 왜 사용할까

요청별로 처리하는 데 드는 비용이 다르다. 가령 주문과 결제 로직을 사용하는 요청의 경우 처리하는 데 드는 시간과 드는 리소스가 더 크고, 반면 단순 이미지를 요청하는 경우는 리소스가 더 작다. 그런데 이 모든 요청을 WAS에게 요청할 경우 값싼 요청을 처리하는 데에도 똑같이 WAS의 리소스를 할당해야 하기 때문에, 이 경우 요청을 먼저 WS가 처리하게 하여서 정적 컨텐츠 요청의 경우는 WAS의 리소스를 아예 사용하지 않도록 할 수 있다. 

✅ WAS는 어떤 기능을 제공하는가

WAS의 큰 장점 중 하나는 서블릿을 지원한다는 것이다. 서블릿을 사용하게 되면 개발자는 비즈니스 로직에만 더 집중할 수 있다. 서블릿에서는 가령 요청이 들어왔을 때 그 요청에서 헤더를 분리하고, 요청의 경로를 확인하고, 파라미터들을 일일이 다 파싱하고... 등등의 작업을 해 준다. 만약 서블릿이 없다면 개발자는 비즈니스 로직 외에도 위의 작업에 필요한 로직을 다 만들어야 했을 것이다. 이럴 경우 작업 효율성이 떨어지고, 코드도 훨씬 더 복잡해졌을 수 있다. 

WAS에서는 서블릿을 지원한다. 요청이 오면 서블릿에서 그 요청을 먼저 처리해서, 위에서 언급한 url 경로를 확인하거나 파라미터 및 헤더를 파싱하는 등의 공통적이고 반복적인 작업을 먼저 처리한다. 그 다음 요청이나 응답을 뷰(MVC 패턴을 쓰는 경우)에서 처리하기 쉽게 요청 및 응답 객체를 새로 생성하여 리턴해 준다. 이는 모든 웹 서버 프레임워크에서 공통적인 것으로 보인다. 지금까지 주로 사용해온 django의 경우도 마찬가지로, view 함수에서는 항상 request 라는 객체를 받았고, 그 안에서 request.headers 등의 기본으로 제공되는 메소드를 통해 요청의 헤더나 파라미터 값들을 쉽게 확인할 수 있었다. 

또한 WAS는 멀티스레딩 기능도 제공한다. 싱글 스레드로 클라이언트의 요청을 처리하게 될 경우, 앞선 요청이 지연되는 경우 뒤의 요청들까지 전부 밀리게 된다. 그렇다고 해서 요청이 들어올 때마다 스레드를 생성하게 된다면 스레드를 생성하는 비용이 비싸고, 그렇게 만든 스레드를 재사용할 수 없어서 비효율적이며, 스레드 간 context switching 비용이 발생하며, 요청을 무한대로 제한 없이 받을 수 있어 과도한 요청이 들어오면 WAS가 다운될 수 있다는 단점이 있다. 그래서 보통은 스레드 여러 개를 모아 둔 스레드 풀을 만들어 두고, 요청이 들어오면 스레드 풀에서 필요한 스레드를 꺼내 쓰는 방식으로 사용한다. 

✅ 궁금한 점들

❓ django WAS는 다른 WAS와는 어떻게 다를까. 서블릿은 어떻게 구현되어 있는지, 또 멀티스레딩은 파이썬에서 어떻게 구현했을지 궁금하다. 

❓ 톰캣에서 사용하는 스레드 풀의 기본 max thread 값은 200개라는데, 현재 개발하고 있는 서비스(onestep)의 경우는 그렇게 많은 스레드가 필요해 보이지는 않는다. 얼마 정도가 적당할지 궁금한데, 아마도 테스트를 통해서 알 수 있을 것 같다. 그러니 테스트도 해 보자.

프로그램을 진행하면서 새 맥북을 받았다! 너무 기뻤지만, 항상 사용하던 윈도우 노트북에서 새 맥북으로 바꾸려니 초기 설정부터 다시 해야 한다는 문제점이 있었다. 

혹시라도 내가 다음에 또 노트북을 바꾸게 되거나, 비슷한 개발자들이 있다면 참고할 수 있도록 하기 위해서 간략하게나마 글을 적어본다. 

✅설치할 프로그램들

1. brew

이 사이트에서 homebrew를 설치할 수 있다. 나는 homebrew는 mac에서 사용하는 일종의 패키지라고 알고 있고, 실제로 앞으로 설치할 많은 프로그램들(git, docker 등)이 brew install ___으로 간단히 설치가 가능하므로, 맥 사용자라면 homebrew 설치는 거의 필수적이라고 볼 수 있다. 

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. git

brew install git

잘 설치되었는지 확인해준다. 

git --version

3. docker

brew install docker

잘 설치되었는지 확인해준다. 

docker --version

4. iterm

필수 사항은 아니지만, 맥에서 기본으로 제공하는 터미널이 예쁘지 않다는 의견이 많아서 내 주변 맥 사용자들도 다 iterm을 사용하는 것 같아서 깔아봤다. 공식 사이트에서 설치할 수 있다. 

5. python

지금 개발중인 프로젝트에서는 python, django를 사용하므로 파이썬도 깔아줬다. 공식 홈페이지에서 맞는 버전을 사용하면 된다. 

6. java

지금 개발에서 사용하는 언어는 아니지만, 앱 개발을 하려면 android studio가 필요하고 android studio에서는 java를 필요로 하기 때문에 결론적으로 java도 필요했다. 주의할 점은, java를 설치하는 방법이 꽤나 여러가지라는 것이다. 그리고 android studio에서 빌드를 실행시키다 보면 jdk와 gradle의 버전이 맞지 않아서 나는 오류가 있다. 

이 사이트에서는 여러 자바 버전을 설치할 수가 있어서 여러 블로그들을 찾아보다 이 사이트에서 특정 jdk 버전을 다운받아서 오류를 해결하였다. 

자바가 잘 설치되었는지 확인하는 명령어는 다음과 같은데, 당연하게도 처음에 이 명령어를 입력하면 java, javac를 인식하지 못한다. 

java -version
javac -version

그 이유는 java에 대해서 환경변수 등록을 해주지 않았기 때문이다. 

맥에서는 루트 폴더 기준으로 .zshrc 라는 파일에 여러 환경변수 경로를 설정할 수 있는데, 이 안에 다음과 같이 입력해 주자. 

참고로 맥에서 파일을 읽거나 쓰기 위해서는 vim 이나 nano 명령어를 사용한다. 그러니까 iterm의 초기 디렉토리에서 다음과 같이 입력하면 아마도 .zshrc 창이 열릴 거다. 

vim .zshrc

여기서 -v 다음에 있는 17의 경우, 나의 경우는 jdk 17을 사용하고 싶어서 제한을 둔 것이다. 만약 다른 버전의 jdk를 명시적으로 사용하고 싶다면 17 대신 다른 숫자를 입력하면 된다. 

export JAVA_HOME=$(/usr/libexec/java_home -v 17)
export PATH=$JAVA_HOME/bin:$PATH

아래와 같은 명령어로 .zshrc 파일에서 변경된 내용을 반영해 준 다음, 다시 자바의 버전을 확인해보면 될 것이다. 

source .zshrc

아 그리고 자바 버전이 여러 개 깔려있을 때에도 중요한 내용인데, android studio에서 사용하는 gradle에서 특정 jdk를 사용하도록 설정하고 싶을 수 있다. 

gradle과 관련된 설정 파일은 보통 iterm의 초기 디렉토리에서(iterm을 열면 맨 먼저 보이는 기본 경로) .gradle > gradle.properties 파일 안에 있다(없으면 그 파일을 만들면 된다). 

파일을 만들고 싶다면 touch 명령어를 사용해 보자. 

touch gradle.properties

이후 vim이나 nano로 해당 파일을 열어준 뒤, 다음과 같이 입력했다. 나의 경우는 다음과 같다. 

org.gradle.java.home=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

org.gradle.java.home 이라는 속성의 값을 java가 위치한 경로로 설정하는 것이 중요하다. 만약 이 경로를 모르겠다면 다음과 같이 입력해서 java가 어디 설치되어 있는지 찾아볼 수 있다. 

which java

나의 경우 이렇게 입력하면

/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java

이렇게 나오는데, 이 중에서 뒤에 /bin/java를 뺀 값을 경로로 지정해 주면 된다. 

7. visual studio code

공식 사이트에서 설치할 수 있다. 

8. android studio

공식 사이트에서 설치할 수 있다. 

Software Release Life Cycle(SRLC)는 소프트웨어를 개발, 테스트 및 배포하는 과정이다. SRLC에는 Pre-alpha, Alpha, Beta, Release Candidate, RTM, GA, Gold 등 여러 단계가 있지만 크게는 소프트웨어를 개발 및 테스트하는 단계와 배포하는 단계로 나눌 수 있다.

Pre-Alpha

SRLC의 첫 단계로, 직접적인 개발을 하기 전 필요한 사항들을 분석한다. 예를 들면 소비자의 요구사항 파악, 필요한 개발 기능 파악이 있다.

Alpha

alpha 배포 단계에서는 앞 단계에서 정의한 문제를 해결하는 잠재적 솔루션(소프트웨어)을 만든다. 프로토타입을 제작하는 것과 같다. 오픈소스가 아닌 이상 대중에게 프로덕트를 공개하지는 않으며, 프로덕트도 서비스의 모든 기능이 추가된 상태는 아니다.

서비스의 일부 기능을 구현하였으나 버그가 있을 수 있으며 데이터 손실 등의 버그도 있을 수 있다. 즉 실제 배포에서 일어나서는 안 되는 종류의 버그들이 있을 수 있다. 그래서 내부적으로 테스트 과정을 거친다.

Beta

pre-alpha에서 기획했던 기능은 다 완성된 상태이나 여전히 버그 가능성은 있다. alpha에서 언급한 데이터 손실, 충돌 등의 문제가 여전히 발생할 수 있다. Beta 단계에서의 목표는 사용성 테스트(usability test)를 통해 실제 유저가 서비스를 사용할 수 있도록 하는 것이다. Beta 단계부터는 테스터를 모집하고, 정식 출시를 하는 소프트웨어도 있다. 인터넷 같은 일부 서비스는 beta 단계에서 계속 머무르기도 한다.

Release Candidate

stable release 버전이 될 가능성이 있는 beta 버전이다. 모든 기능들이 개발된 버전이다. beta 버전 사이클을 1번 이상 거치고, 중대한 버그(데이터 손실, 충돌 등)가 발생하지 않은 상태이지만 자잘한 버그의 수정은 있을 수 있다. 보통 이 단계까지를 개발 단계로 보고, 그 다음부터는 배포 단계로 본다.

GA(General Availability)

프로덕트가 상업적으로 이용 가능한 상태가 된다. 이 단계에서도 프로덕트가 수정될 수는 있는데, 버그 수정 등의 오류가 아니라 더 상품성을 높이기 위해서 수정된다. 예를 들면 보안 기능이나 여러 지역에 서비스를 배포하는 것 등이 해당한다.

Production Release(Stable Release)

정식 배포가 된 상태이다.

참고한 포스트

https://ausdto.github.io/service-handbook/alpha/1-introduction/1-1-what.html

https://en.wikipedia.org/wiki/Software_release_life_cycle

https://theproductmanager.com/topics/software-release-life-cycle/

해당 게시물은 유튜브 생활코딩 채널의 WEB2-OAuth 강의를 듣고 작성한 포스트입니다.

WEB2 - OAuth 2.0 : 1.수업소개 - YouTube

강의 목표

OAuth 개념 이해하기

1. OAuth의 개념

OAuth를 사용하는 대표적인 예시로는 소셜로그인이 있다. 하지만 소셜로그인만이 전부가 아니다.

OAuth는 다른 서비스(보통은 신뢰할 수 있는 서비스. ex) google, facebook)와 원래 서비스를 연동한다. 
그러려면 사용자가 사용하는 해당 서비스 계정에 접근할 수 있도록 허가를 받아야 한다. 

가장 쉬운 방법은 사용자의 개인정보(아이디, 비밀번호) 등을 전달받아서 이를 SNS 계정에 접근할 때 이용하는 것이다.
그러나 사용자 입장에서는 자신의 개인정보를 처음 보는 서비스에게 맡기는 것은 불안하고, 보안상 문제가 있을 수 있다. 

OAuth는 이런 방법 말고, 토큰(Token)을 사용해서 안전하게 서로 다른 두 서비스가 상호작용할 수 있도록 해 준다. 

OAuth의 장점

1. 사용자의 실제 개인정보를 본래 사이트에서 사용하지 않는다. 즉 보안 면에서의 장점이 있다. 
2. 액세스 토큰으로 이용할 수 있는 SNS 서비스를 제한할 수 있다.

바로 위의 언급한 방법처럼 사용자의 실제 개인정보를 통으로 넘겨주게 되면, 해당 사이트에서 사용자 계정의 모든 권한을 갖는다는 점에서 보안 문제가 있다. 반면 액세스 토큰으로는 할 수 있는 일과 없는 일이 제한되어 있다. 마찬가지로 보안에서의 장점이 있다.

OAuth를 사용하는 방법

사용자의 개인정보를 사용해서, 사용하려는 다른 서비스의 사이트에서 로그인한다. 

사용자가 로그인하면 사용자의 실제 개인정보 대신 액세스 토큰을 발급하고, 본래 사이트에서 그 토큰으로 다른 서비스와 상호작용할 수 있다. 

2. 역할

Oauth에 등장하는 3개의 주체

resource owner : 사용자 
resource server : 기존 사이트에서 제어하고 싶은 자원을 갖고 있는 서버
client : 리소스 서버의 자원을 이용하려는 사이트

OAuth 공식 문서에서는 리소스 서버(resource server)를 resource server와 authentication server로 분리한다. 
resource server : 인증에 필요한 데이터를 갖고 있는 서버
authentication server : 인증 처리 및 작업을 하는 서버

*간단하게 보면 둘을 묶어서 그냥 리소스 서버로 보기도 한다. 

3. 등록

리소스 서버에 클라이언트를 등록하는 절차

클라이언트가 리소스 서버의 리소스를 사용하려면 사전에 미리 등록(register)을 해야 한다.

(Create app 이라는 과정으로도 나온다.)

등록에 필요한 정보

client id : 리소스 서버에서 개별 클라이언트에게 부여하는 id. 노출이 되어도 상관없다. 
client secret : 클라이언트가 리소스 서버에 자신을 인증할 때 사용하는 비밀번호. 노출되어서는 안 된다. 
authorized redirect urls : 리소스 서버는 이 url로 클라이언트에게 authorization code를 보낸다. 
만약 이 url이 아닌 다른 url에서 리다이렉트(redirect)요청이 들어온다면, 리소스 서버는 해당 요청에 대해서 응답을 보내지 않는다. 

실제로 등록하는 방법

사용하려는 리소스 서버 서비스의 developers 사이트에 가서, create app 또는 비슷한 메뉴를 찾아보자. 

ex)
Facebook : developers facebook 사이트에서 create app 메뉴 선택
Google : cloud platform 사이트에서 select/create project 메뉴 선택

4. Resource Owner의 승인

리소스 서버에 클라이언트가 사전 등록 작업을 마쳤다고 해 보자. 

클라이언트 서비스에서 리소스 오너의 정보로 리소스 서버의 서비스나 리소스를 이용하려면 추가적인 작업이 필요하다. 

우선 리소스 오너의 승인이 필요하다. 

ex. 리소스 유저가, 클라이언트 사이트가 나의 정보를 가지고 리소스 서버 사이트의 특정 기능을 사용하는 것을 승인

그 다음엔 리소스 서버의 승인도 필요할 것이다. 

ex. 리소스 서버 사이트에서 액세스 토큰과 같이 보낸 요청을 승인

과정

우선 등록이 완료된 이후, 클라이언트와 리소스 서버가 oauth에 필요한 어떤 정보를 갖고 있는지를 보자. 

클라이언트가 리소스 서버에 등록했을 때 사용한 client id, client secret, redirect URL의 정보를 둘 다 갖고 있다. 

만약 리소스 오너가 클라이언트 사이트를 이용하면서 소셜로그인 등의 '리소스 서버의 리소스를 필요로 하는 서비스'를 사용하려고 한다면, 흔한 소셜로그인 버튼 등이 나타날 것이다. 

리소스 오너가 그 버튼을 누르면(http 요청을 하면), 클라이언트 사이트는 응답과 함께 리다이렉트 URL을 리턴한다. 

리다이렉트 URL 예시

https://resource.server/?client_id=1&scope=B,C&redirect_url=https://client/callback

리다이렉트 URL은 리소스 서버와 클라이언트가 공통으로 가진 3개의 정보(client_id, client_secret, scope)중에서 client_secret을 제외한 2개의 정보를 쿼리 스트링으로 포함하고 있다. 

해당 url을 받은 리소스 오너는 받은 리다이렉트 url으로 리소스 서버에게 GET 요청을 보낸다.

(POST 처럼 따로 데이터를 담아서 보내지는 않는다.)

만약 해당 리소스 오너가 이미 리소스 서버에 로그인이 되어 있지 않은 경우(관련 토큰이 헤더에 없는 경우), 리소스 서버는 리소스 유저에게 리소스서버 로그인을 요청한다. 

참고로 로그인을 하지 않은 상태에서는 리소스 서버는 url 파라미터인 client_id, redirect_uri, scope는 아직 보지 않는다. 

여기서 리소스 오너가 로그인을 하면 다음 단계로 넘어간다. 

또는 이미 로그인이 되어 있었다면(관련 토큰을 헤더에 같이 넣어서 보냈다면), 리소스 서버는 이때 client_id와 redirect_uri를 확인한다. 

(만약 리소스 서버가 갖고 있는 client_id, redirect_uri 파라미터가 맞지 않는다면, 리소스 서버는 여기서 응답을 종료한다.)

만약 클라이언트가 보낸 값이 리소스 서버의 값과 일치한다면, 리소스 서버는 리소스 유저에게 클라이언트 사이트에서 scope에 해당하는 권한을 클라이언트에게 부여해도 되는지를 물어본다. 

(선택하는 작은 폼이 뜰 것이다.)

클라이언트가 해당 폼에서 allow를 누르면, 리소스 서버에는 리소스 유저의 id와 해당 리소스 유저가 허용한 scope 변수의 값이 저장된다. 

저장하는 이유는, 앞으로 해당 리소스 유저의 액세스 토큰으로 리소스 서버의 서비스나 리소스를 이용할 때, 해당 유저가 어떤 scope의 권한을 허용했는지를 알 수 있게 정보를 저장하는 것이다. 

5. Resource Server의 승인

리소스 유저가 scope에 대한 권한을 클라이언트에게 부여하는 걸 허용했다고 해도, 리소스 서버가 바로 액세스 토큰을 부여하지는 않는다. 

절차가 하나 더 있다.

리소스 유저가 scope에 대한 권한을 승인하고, 리소스 서버가 user_id와 scope를 저장한 이후, 리소스 서버는 리소스 유저에게 authorization_code를 리턴한다. 

authorization_code : 리소스 서버가 클라이언트를 인증하는 임시 비밀번호 역할을 한다. 

authorization_code는 아까 리소스 유저가 리소스 서버에게 보냈던 redirect_uri 파라미터 주소의 뒤에 쿼리 스트링을 추가한 형식으로 붙어서 보내진다. 

https://client/callback/?code=3

이 정보를 리소스 유저에게 응답으로 보낼 때, 리소스 서버는 이 정보를 헤더의 Location 파라미터에 넣어서 보낸다. 

그러면 리소스 유저의 브라우저는 location 파라미터에 있는 주소로 리다이렉트를 하게 된다. 

그러면 리소스 유저는 클라이언트에게 해당 url로 GET 요청을 보내는 셈이다. 

(redirect_uri의 도메인이 클라이언트의 도메인이기 때문이다)

그러면 클라이언트는 이제 authorization_code의 값도 알게 된다. 

이제 클라이언트는 리소스 유저를 통하지 않고, 리소스 서버에게 직접 요청을 보낼 수 있다. 

쿼리 스트링 파라미터로 url에 값을 넣은 형식이고, GET 방식으로 요청을 보낸다. 

url 예시

https://resource.server/token?grant_type=authorization_code&code=3&redirect_url=https://client/callback&client_id=1&client_secret=2

해당 url에는 grant_type, code, redirect_url, client_id, client_secret 정보가 포함되어 있다. 

이 중에는 2개의 비밀번호(auth_code, client_secret) 정보도 포함되어 있다.

+

강의에서 다루진 않았지만, 리소스 서버가 클라이언트를 인증하는 방법은 authorization code로 인증하는 방법 말고도 여러 개가 있다고 한다. 그래서 어떤 인증방법을 사용하는지에 대한 정보를 알려주기 위해서 

grant_type=authorization_code

라는 쿼리스트링이 붙는다. 

개인적인 Q

리소스 정보는 자신의 DB에서 client_secret, auth_code 정보가 클라이언트가 보낸 정보와 일치하는지를 보고(ex. client_secret=2인 계정의 auth_code는 3이 맞는지), client_id, redirect_url 등의 나머지 정보가 맞는지도 확인한다. 

이제 다음 단계에서 액세스 토큰을 지급한다.

6. 액세스 토큰 발급

이제는 리소스 서버가 클라이언트에게 직접 액세스 토큰을 발급한다. 

해당 액세스 토큰은 리소스 서버와 클라이언트의 DB에 각각 저장되며, 각 리소스 유저마다 당연히 액세스 토큰의 값이 다르다. 

처음에 리소스 유저가 한번 '클라이언트에서 자신의 리소스 서버 계정에서 특정 기능들(scope)의 접근 권한을 얻는 것'에 동의하면, 그 이후로는 별도의 동의를 받지 않고 액세스 토큰을 사용할 수 있다. 

순서

1. 리소스 유저가 클라이언트 사이트에서 '소셜로그인' 등의 버튼을 클릭한다(클라이언트에게 요청을 보낸다).

2. 클라이언트는 리소스 유저에게 리다이렉트 응답을 보낸다(리소스 서버 로그인으로 리다이렉트).

3. 정보를 맞게 입력한 경우 기존에는 authorization_code를 보내서 추가 인증을 진행하였지만, 이제는 그러지 않는다. 

셀프 Q&A

7. API 호출

oauth를 이용하는 가장 중요한 목적

액세스 토큰 발급 이후 리소스 서버의 일부 기능을 사용하려면 리소스 서버의 API를 사용해야 한다. 

리소스 서버의 API는 리소스 서버에서 제공하는 여러 기능을 어떻게 사용할 것인지에 대한 표준 규격이라고 할 수 있다. 

각 리소스 서버는 API들을 어떤 형식으로, 어떤 파라미터 등을 넣어서 사용해야 하는지에 대한 정보를 공식문서로 제공하고 있다. 

ex. "구글 캘린더 API" 를 검색해서 나온 공식문서를 참고해서, 해당 형식으로 요청 보내면 데이터를 받을 수 있다. 

액세스 토큰 보내는 방법(2가지)

1. GET 요청으로 url 쿼리스트링에 access_token={access_token} 값 넣어서 보내기

상대적으로 간편하지만 보안 측면 때문에 덜 사용된다고 한다. 

2. GET 요청으로 보내되, 액세스 토큰은 헤더에 Authorization 값으로 넣고, Bearer 토큰 방식으로 보내기

보안 측면에서 더 좋다. 다만 일반적인 url 접근이 불가능하고, curl이나 postman같은 프로그램을 사용해야 한다. 

8. 리프레쉬 토큰 Refresh Token

액세스 토큰은 유효기간이 있다. 

리프레쉬 토큰은 처음 액세스 토큰이 발급될 때 액세스 토큰과 같이 발급되는데, 액세스 토큰이 만료되었을 때 새 액세스 토큰을 발급하는 데 사용된다. 

액세스 토큰을 발급받을 때는 보통 액세스 토큰, 리프레쉬 토큰, 만료기간의 값을 같이 리턴하는 것이 일반적이다. 

리프레쉬 토큰이 어떻게 발급되는지도 마찬가지로 사용하려는 각 리소스 서버의 공식문서를 참조하면 알 수 있다. 

ex. 구글의 경우 Google Identity Platform에서 관련 정보를 제공한다. 보통은 특정 url로 필요한 정보(client_id, grant_type, refresh_token 등)를 POST 방식으로 보내면 새 액세스 토큰을 발급하는 방식을 많이 쓴다. 

또한 리프레쉬 토큰의 경우, 새 액세스 토큰의 발급에 사용되면:

(1) 리프레쉬 토큰 값도 새로 발급해 주는 경우도 있고, 

(2) 리프레쉬 토큰 값은 그대로인 경우도 있다. 

9. 수업을 마치며

앞으로 공부해 볼 만한 주제

federated identity : 다른 서비스와의 연합을 통해 사용자를 식별하는 인증체계

RESTful API : 많은 형식의 API는 이 방식을 따르고 있다. 

💎목차

✔️인증의 정의

✔️세션과 토큰의 차이점

✔️API를 인증하는 여러 방법들

✅인증(Authentication)

인증 - 사용자의 개인정보를 사용하여 사용자가 누구인지를 판단

인가 - 사용자가 어떤 일을 할 수 있는지,어떤 권한을 갖고 있는지를 판단

사용자의 개인정보(아이디나 비밀번호)를 직접 인증에 사용하거나 인증을 위해 주고받는 방법은 정보 노출의 위험이 있어서 잘 사용하지 않는다. 대신 사용자의 개인정보를 인코딩 하거나, 해쉬 알고리즘을 통해 암호화한 뒤 이 정보를 주고받을 수는 있다. 

암호화에는 여러 가지 방법이 있다. Base64 인코딩을 거친 정보를 암호화하는 방법도 있고, 클라이언트와 서버만 아는 난수를 생성한 뒤 이를 해쉬 알고리즘에 넣어서 암호화하는 방법도 있다. 

그럼 암호화한 정보를 어떻게 사용할까? 클라이언트가 매번 서버에 리소스를 요청할 때마다 암호화를 통해 인증을 하는 것은 매우 번거롭고 시간도 오래 걸린다. 보통은 로그인 등으로 한 번 인증 절차를 거치면 일정 기간동안은 별도의 인증 절차 없이 리소스에 접근할 수 있도록 되어 있다. 

이처럼 사용자가 이미 인증 절차를 거쳤음을 증명하는 데 사용하는 것이 세션(session), 토큰(token) 등의 개념이다. 

✅세션과 토큰

토큰과 세션은 모두 사용자를 일정 기간동안 유효하게 인증하는 데 사용하는 방식인데, 인증하는 방식에 따라서 차이가 있다. 예전에는 세션을 많이 사용했다면 요즘은 세션의 단점을 보완한 토큰을 더 많이 사용하는 추세이고, 그 중에서도 json 형식으로 되어있는 JWT(json web token)를 많이 사용한다. JWT에 대해서는 뒤 부분에서 구체적으로 다뤄 보자. 

🌟JWT와 세션의 차이

JWT가 활성화되기 전에는 세션을 통한 인증이 활발했으나, 세션은 요청할 때 인증을 위해서 DB를 탐색해야 하는 단점이 있었다. 세션 관련 정보는 DB에 저장되었기 때문이다. 
물론 캐시(cache memory)를 이용해서 세션 정보를 브라우저에 임시로 저장할 수 있긴 하지만, 만료되거나 신규 요청이 들어오면 결국 DB를 탐색해야 했다. 
만약 세션 정보를 저장하는 DB가 분산되어 있다면 각각의 DB를 탐색해야 하는데, 이는 규모가 커질 경우 과정이 복잡해질 수도 있었다. (물론 요즘은 세션을 백엔드에서 편리하게 관리해 주는 프레임워크도 있다.)

JWT는 이런 세션의 단점을 보완한다. 

대략적인 인증 과정은 비슷하다.

클라이언트가 인증 요청을 하고, 서버가 인증을 처리하고 세션이나 JWT를 생성하면 이때 생성한 정보를 만료되기 전까지 일어나는 모든 인증에 사용하는 방식이다.

그러나 세션은 인증 정보를 DB에 저장하지만 JWT는 인증 정보를 클라이언트에 전달하고, 클라이언트가 브라우저에 JWT 토큰을 임시 메모리 형태로 저장한다. 

그렇다면 클라이언트가 API에 대해서 인증 요청을 할 때, 토큰을 어떻게 생성하고 인증할까? 

🌟API에서 토큰을 생성 및 인증하는 방법

순서

1. 사용자의 개인정보를 이용하여 사용자가 맞는지 판단하고(로그인), 사용자가 맞다면 토큰을 발급한다. 

2. 발급한 토큰은 API 접근 토큰 테이블에 등록된다. 

3. 사용자가 인증이 필요한 API를 요청할 경우, 서버는 사용자가 API 토큰이 있는지, 그리고 토큰이 유효한지(위조된 토큰인지, 유효 기간이 지났는지 등)를 확인해서 토큰이 유효하다면 사용자에게 API나 리소스를 제공한다. 

장점

API 토큰을 주고받는 중 해킹이 일어나도 사용자의 개인정보는 탈취되지 않는다. 토큰은 사용자의 정보와는 관계없는 임의의 문자열이기 때문이다. 

✅API 토큰 인증의 세부 방법(여러가지가 있음)

🌟Base 64 인코딩

클라이언트가 처음에 사용자가 맞는지를 개인정보로 인증할 때, 당연히 그 개인정보를 '직접' 보내지는 않는다. 
클라이언트는 자신의 개인정보를 Base64 인코딩을 거친 뒤, 토큰에 넣어서 서버에게 인증 요청을 보낸다. 그러면 서버가 그 정보를 바탕으로 사용자를 인증한다. 

다만 Base64는 별도의 키 값이 없기 때문에 인코딩한 문자열을 그대로 디코딩할 수 있다. 따라서 이 방법을 쓰려면 반드시 HTTPS 프로토콜을 이용해야 한다. 
안 그러면 해커가 중간에서 정보를 탈취할 수 있고, 탈취한 정보를 그대로 디코딩하면 사용자의 정보가 그대로 노출된다. 

🌟Digest Access Authentication

Base64의 단점을 보완한다. 
클라이언트가 서버에게 인증을 요청할 때, 서버는 클라이언트에게 임의의 난수 값을 준다. 
클라이언트는 이 난수 값을 해쉬 함수의 키 등으로 이용하여, 암호화한 결과를 토큰에 실어서 서버로 전송한다. 

이 경우 토큰 안에 일반 문자열(평문)으로 정보가 담겨 있지 않다. 또한 해커가 인증에 사용된 해쉬 알고리즘을 안다고 하더라도, 난수 키를 모르기 때문에 해시된 값에서 반대로 개인정보를 추출해 내기가 더 어렵다. 

📋인증 범위(Realm)

여러 API에 대해서 인증 범위(realm)을 다르게 설정할 수 있다. 
realm은 보호되는 영역인데, API 전체를 부분적으로 나눠서 다른 realm에 위치시킬 수 있다. 
realm을 사용하면 서버가 보호하고 있는 API를 여러 영역으로 나눌 수 있고, 각 영역(realm)마다 요구되는 정보(사용자 이름이나 비밀번호)를 다르게 지정할 수 있다. 

예를 들면 project API는 A realm, homework API는 B realm에 위치시킨다고 해 보자.
만약 클라이언트가 project API에 대해 인증을 요청한다면, 서버는 사용자가 A 영역(realm)에 접근을 시도했다고 보고 그에 맞는 개인정보를 받아 사용자가 맞는지 판단한다. 
반면 클라이언트가 homework API에 대해 인증을 요청한다면, 서버는 사용자가 B 영역(realm)에 접근을 시도했다고 보고 A영역과는 다른 개인정보를 받아 사용자가 맞는지 판단한다. 

만약 project API와 homework API가 모두 같은 A realm에 위치해 있었다면, 클라이언트가 project, homework API에 대해 각각 인증을 요청할 때 서버는 사용자가 모두 A 영역에 접근을 시도했다고 보고, 토큰을 발급하는 데 같은 정보를 사용했을 것이다. 

즉 realm이 다르다는 것은 클라이언트가 각각 여러 API에 인증 요청을 보낼 때, 클라이언트는 각각 다른 정보를 사용하여 다른 유저로 인증될 수 있다는 의미이다. 

🌟화이트 리스트

API를 호출하는 클라이언트의 API가 일정할 때, 클라이언트가 고정 IP를 사용할 때 사용할 수 있다. 

서버는 특정 API URL에 대해서 들어오는 IP 주소를 화이트 리스트로 유지할 수 있다. 

화이트 리스트

기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식이다. 
화이트 리스트에 등록된 IP가 아니면 모두 접근을 허용하지 않고, 화이트 리스트에 등록된 IP에 대해서만 인증 절차를 거쳐서 접근이 가능하도록 배치한다. 

🌟Oauth

제 3자 인증 방식 중 하나이다. 소셜로그인이 대표적인 예시이다. 
사용자 A가 웹 서비스 B의 리소스(API 등)에 접근하기 위해서, 다른 API 서비스 제공자 C(구글, 페이스북 등 소셜로그인이 가능한 서비스들)에게 인증 요청을 보낸다. 
A가 알맞은 정보로 인증하면, C는 A에게 유효기간이 있는 액세스 토큰을 지급한다. 
그러면 A는 C에게서 받은 토큰을 가지고 B의 리소스를 이용할 수 있다. 

🌟JWT(Json Web Token)

웹에서 토큰을 보낼 때 json 형식으로 주고 받는 토큰이다.

JWT는 claim 기반을 사용한다. claim(클레임)이란 유저의 속성을 의미하는데, 말 그대로 토큰 자체에 유저에 대한 정보가 포함되어 있다. 
이와 달리 Oauth는 토큰에 아무 의미가 없는 랜덤 문자열을 넣는다. 

따라서 JWT 토큰을 발급하면 토큰 내에는 사용자 정보가 포함되기 때문에(정확히는 Base64로 인코딩한 정보가 포함) 서버가 사용자의 정보를 다른 곳에서 추가로 찾거나 가져오지 않아도 된다는 장점이 있다.

반면 토큰 내에 모든 정보가 들어 있기 때문에, 토큰을 잘못 발행했어도 중간에 수정할 수 없다.

따라서 JWT 토큰에는 꼭 유효 기간을 지정해야 하고, 중간마다 리프레시 토큰으로 토큰을 재발행 해야 한다.

뿐만 아니라 토큰은 Base64 인코딩만 된 상태이기 때문에 중간에 누군가가 가로챌 경우 사용자의 정보가 노출될 수 있다.

이런 경우엔 토큰 자체를 암호화하는 JWE를 사용하기도 한다. JWT는 JWE 등으로 암호화를 하더라도, 복호화가 가능하다. 

☑️JWT 토큰의 구조

크게 세 가지 영역: 헤더(Header), 페이로드(Payload), 시그니처(Signature)로 나뉜다. 

토큰 예시: hhhhh.ppppp.sssss

1. Header(헤더)

토큰의 메타 정보가 담겨져 있다. 

어떤 방식으로 인코딩 되었는지, 토큰이 어떤 타입(JWT, Oauth 등)인지 등을 json 방식으로 작성한 뒤 해당 방식에 맞춰서 인코딩한다. 

2. Payload(페이로드)

사용자의 정보, 토큰의 만료 시간 등이 담겨져 있다. 

이때 사용자의 정보는 id 등 사용자를 특정할 수 있는 정보이다. (유저의 아주 중요한 정보(주민번호 등)가 담기진 않았지만, 하나의 유저를 특정할 수 있는 정보가 들어 있다.)

3. Signature(시그니처)

변조 문제를 해결하기 위한 영역이다. 

시그니처 영역을 만들기 위해서는 인코딩 된 헤더, 인코딩 된 페이로드, 그리고 secret_key(장고 프로젝트마다 사용되는 값) 값이 필요하다. 

시그니처는 이 세 값을 합친 뒤, 헤더에 지정한 알고리즘으로 해싱한다. 

그러므로 하나라도 값과 다르다면 결과값이 달라진다. 

☑️실제 인증하는 과정

기존에 만들어진 JWT 토큰은 브라우저에 캐시 형태로 저장되어 있다. 클라이언트가 서버에 특정 리소스에 대해서 인증을 요청한다고 하자. 

그러면 [클라이언트가 요청과 함께 보낸 토큰의 시그니처 값] == ([토큰 헤더 인코딩한 값] + [토큰 페이로드 인코딩한 값] + [장고 각 프젝마다 있는 secret_key 값])=>해시 알고리즘 적용

이 두 값이 같은지를 비교해서, 같다면 사용자 인증을 허가한다. 

참고한 포스트

https://dongwooklee96.github.io/post/2021/03/28/rest-api-%EB%B3%B4%EC%95%88-%EB%B0%8F-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D/
https://hamait.tistory.com/416
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate
https://www.qu3vipon.com/django-jwt

Cron이란?

지정된 시간에 지정한 업무를 해 주는 프로그램으로, 주로 리눅스 운영체제에서 많이 사용한다. 

cron에 등록된 업무들은 cron 디렉토리 내부의 파일에 저장된다.

cron 디렉토리

/var/spool/cron/crontabs 또는 /var/spool/cron/

그러나 cron으로 등록된 업무를 추가, 수정 및 변경하고 싶다면 직접 파일을 변경해서는 안 된다. 터미널에서 crontab 이라는 명령어를 사용해서 변경하자. 

cron 파일의 구성

cron 파일은 명령어, 환경설정, 주석 이렇게 세 종류의 라인으로 구분된다. 

✅cron 스케줄링

cron에 업무를 등록해서 수행하게 하려면, 어떤 시간에 어떤 업무를 수행할지 알려주어야 한다. 

{분 시간 일 월 요일} {수행할 업무가 저장된 파일 경로}

분, 시간, 일, 월, 요일은 모두 숫자로 작성하고, 파일 경로는 해당 cron shell의 경로에서 상대 경로로 입력한다. 

- 분: 0-59

- 시간: 0-23

- 일: 1-31

- 월: 1-12

- 요일: 0-7 (일요일이 0 또는 7이다)

-나 ,를 사용해서 각 필드를 연속된 값, 또는 각각 떨어진 값들로 지정하는 것도 가능하다. 

0 0 1,2 * *		# 매월 1일과 2일 정각에 실행
0 0 * * 1-3		# 매주 월, 화, 수 정각에 실행

매번 진행하다 보면 cron 실행 시간이 유효하지 않을 수 있다. 

ex) 매월 31일에 실행했을 때, 6월 31일은 없다. 

이 경우, 유효하지 않은 경우는 업무를 진행하지 않는다. 

즉 매월 31일에 실행한다고 입력하면 실제로는 2, 4, 6, 9, 11월에는 업무가 실행되지 않는다. 

✅crontab 명령어 사용법

1) 변경

해당 명령어 뒤에 변경할 내용을 입력하면 그대로 변경된다. 

$ crontab -e

2) 현재 명령어 보기

cron에 등록된 명령들을 변경하지 않고 조회만 할 수 있다. 

$ crontab -l

3) 삭제

현재 접속한 유저 계정으로 등록된 모든 cron 명령들을 삭제한다. 

$ crontab -r

4) (root 유저로 접속 시) 다른 유저의 crontab 업무 변경/조회/삭제

$ crontab -u certainUser -e		# 변경
$ crontab -u certainUser -l		# 조회
$ crontab -u certainUser -r		# 삭제

✅cron 주석(comment)

여느 프로그래밍 언어처럼 cron 파일에도 부가적인 설명 등을 추가할 수 있는 주석 기능이 있다. 

주석은 라인 단위로만 달 수 있고, 라인 중간부터 주석을 선언하는 것은 불가능하다. 

주석을 달려면 해당 라인의 첫 문자를 # 으로 시작하면 된다. 

✅cron 환경설정

cron 프로그램의 실행에 관여하는 환경변수를 설정하거나, 기존 환경변수의 값을 바꿀 수 있다. 

cron 파일은 위에서부터 아래로 읽기 때문에, 처음부터 어떤 변수를 특정 값으로 정해 두고 싶다면 해당 환경설정 명령어를 맨 윗 줄에 위치시키면 된다. 

✔️SHELL

cron 프로그램이 작동하는 shell의 위치를 저장한 변수이며, 기본값은 /bin/sh 으로 설정되어 있다. 

$ SHELL = /bin/sh

✔️MAILTO

cron 프로그램은 등록한 작업을 수행하면 기본값으로 해당 작업을 등록한 유저의 계정으로 메일을 보내도록 되어 있다. 

즉 MAILTO = {해당 유저의 메일 주소}로 되어 있다. 

만약 메일을 받고 싶지 않다면 MAILTO = "" 으로 바꿔 주자. 

그런데 메일을 안 받으면 수행된 cron 작업에 대한 메시지는 저장되지 않고 사라진다. 

따라서 다른 방법을 사용하는 것이 일반적이다. 

1. cron 업무 기록을 파일에 저장하기

(1) overwrite - 덮어쓰기

{cron 작업 내용} echo "메시지" > 저장할 파일명.log

0 * * * * echo "Hourly message." > message.log

해당 파일의 내용을 덮어쓴다. 해당 cron 업무가 이후에 또 수행되면, 해당 파일의 내용을 새 기록으로 대체한다. 

따라서 cron 업무 내용을 누적해서 기록하고 싶다면 덮어쓰기보다는 이어서 쓰는 것이 좋다. 

(2) append - 이어쓰기

{cron 작업 내용} echo "메시지" >> 저장할 파일명.log

0 * * * * echo "Hourly message." >> message.log

2. cron 업무 중 오류가 난 경우만 파일에 저장하기

{cron 업무 내용} > /dev/null

/dev/null 은 특정 경로라기보다는 리눅스 운영체제에만 있는 특별한 종류의 파일이다. 해당 파일에 기록된 내용은 기록된 즉시 바로 삭제된다. 그러므로 사용자는 오류가 난 경우가 아니면 알림이나 기록을 받지 않을 수 있다. 

참고한 포스트

Working with Cron Jobs - HostDime Knowledge Base

Git: clone, single-branch, checkout

clone

보통 공동으로 작업할 때 깃(git)을 많이 사용하는데, 깃에는 두 개의 저장소 개념이 있다. 

사용자의 PC는 로컬 저장소, 깃허브 리포지토리는 원격 저장소라고 한다. 

git clone 명령어를 사용하면 원격 저장소에 저장된 코드를 로컬 저장소로 가져올 수 있다. 

git clone {리포지토리 url(http)}

리포지토리 url은 깃 리포지토리 화면에서 code 버튼을 눌러서 얻을 수 있다. 

지금은 http url을 기준으로 리포지토리를 가져오는 방법을 알아보았지만, 나중에는 ssh를 기준으로 리포지토리를 가져오는 방법도 알아봐야겠다. 

branch

git에는 브랜치(branch)라는 개념이 있다. 하나의 나무에서 여러 개의 가지(branch)가 나온다고 생각하면 편하다.

기본 중심은 master 브랜치이다.

다른 브랜치끼리 서로 합칠 수도 있고, 하나의 브랜치에서 다른 브랜치를 만들어 낼 수도 있다. 

여러 개의 브랜치를 만들지 않고 모두가 하나의 브랜치에서 작업한다고 가정해 보자.

깃허브에 작업 내용을 반영할 때, 각자의 코드가 다른 부분이 생기면 그 때마다 충돌이 발생한다.

물론 나중에는 불일치를 해결해야 하겠지만, 깃허브에 코드를 올릴 때마다 이 충돌을 해결하는 것은 번거로울 수 있다. 

하지만 브랜치가 있다면 각자의 브랜치에서 작업하고, 나중에 여러 개의 브랜치를 하나로 합칠 때만 이 충돌을 해결해 주면 된다.

따라서 깃허브에 코드를 올릴 때마다 충돌이 발생할 걱정이 없다. 

이처럼 브랜치는 하나의 프로젝트를 여러 목적에 따라서 나눌 때(개발용 브랜치, 실제 배포용 브랜치, 테스트용 브랜치 등등), 또는 사용자마다 다른 브랜치를 사용한 다음 하나로 합칠 때도 사용한다. 

single-branch

위에서 clone으로 깃허브의 코드를 가져올 때, 해당 리포지토리에는 여러 개의 브랜치가 있을 수 있다. 

이때 특정 브랜치의 코드만 가져오고 싶을 때 사용하는 것이 single-branch이다. 

즉 single-branch를 사용하면 원격 저장소에서 전체를 다운받는 것이 아니라, 개별 브랜치의 내용만 가져오는 것이 가능하다. 

git clone -b {브랜치 이름} --single-branch {리포지토리 url}

checkout

single-branch와 달리, 이번에는 리포지토리의 모든 브랜치의 코드를 가져왔다고 해 보자. 

이때 때로는 작업하는 브랜치를 바꿔 가면서 개발해야 하는 상황도 있다. 

checkout을 사용하면 필요할 때마다 현재 작업하는 브랜치를 바꾸면서 작업할 수 있다. 

참고로 checkout의 기본 브랜치는 origin, 즉 master 브랜치이다. 

git checkout {브랜치 이름}