[Git] 깃허브(GitHub) Private Repository 접근 방법2: Token
토큰의 개념
토큰(token): n. (화폐 대용으로 쓰이는) 토큰, a.(약속, 합의 등을 지키겠다는) 징표[표시]로 하는, 예고성의
즉, 토큰은 미리 약속한 징표.
토큰 인증 방식은 사용자가 발급받은 토큰 정보를 서버에 전송하여 해당 토큰을 검증한 뒤 인증받는 방식이다.
토큰에는 인증에 필요한 데이터들(사용자 정보, 유효기간, 디지털 서명 등)이 암호화되어 있어서 따로 서버에서 저장을 해두지 않아도 된다는 장점이 있다.
하지만 토큰이 가진 데이터의 길이가 길어서 인증 요청이 많을 경우 네트워크에 부하가 생길 수 있다. 또한 만료의 개념이 있기 때문에 만료일이 지날 때마다 갱신을 해주어야 한다.
토큰 로그인 방식을 자주 사용하는 분야 중 하나는 모바일 앱이다.
웹의 경우 쿠키를 이용하여 클라이언트와 서버가 필요한 정보를 주고받지만 앱은 그러한 시스템이 없다. 그렇기 때문에 세션 로그인 방식을 이용하기 위해서는 세션 IDID 전송과 수신을 직접 구현시켜야 한다.
또한 앱의 경우 백그라운드 상태로도 흔하게 전환될 수 있기 때문에 백그라운드로 전환 시 세션이 만료될 수 있으며 이에 대한 로직을 따로 짜야한다는 번거로움이 있다.
토큰은 세션 로그인 방식과 다르게 StatelessStateless 한 성질을 가지고 있기 때문에 이러한 점에서 지속적으로 연결(Stateful)이 되어있어야 하는 세션 방식보다 앱에 더 적합하다.
| 세션 로그인 vs 토큰 로그인 세션 로그인: 사용자가 사용자 정보를 서버에 보냄(로그인) -> 서버가 사용자에 대한 정보가 담긴 데이터베이스에서 사용자를 찾아 세션ID 전송 + 로그인 상태에 대한 정보 저장 -> 사용자는 세션ID를 받고 데이터 요청 시 이용 -> 세션ID를 받은 서버는 ID확인 후 요청한 데이터 전송 토큰 로그인: 사용자가 사용자 정보를 서버에 보냄(로그인) -> 서버가 토큰 발급하여 사용자에게 전송 -> 사용자는 데이터 요청 시 토큰을 함께 보냄 -> 서버가 토큰을 검증한 후 요청한 데이터 전송 세션 로그인은 클라이언트의 로그인 상태를 저장해둔다. 따라서 지속적으로 연결이 되어있다고 해서 statefull하다고 표현한다. 반대로 토큰 로그인은 로그인과 관련한 정보를 서버에서 저장해두지 않고, 요청할 때마다 검증하여 요청한 데이터를 보내주는 방식이기 때문에 지속적으로 연결된 상태를 유지하지 않아 stateless라고 표현한다. 이러한 차이 때문에 세션 로그인 방식을 이용하기 위해서는 사용자의 정보를 담아둘 수 있는 DB가 필요하다. 그렇게되면 사용자나 로그인 기기가 많아졌을 경우에 DB의 관리에 대한 고민히 필요해진다. 반면에 토큰은 서버가 토큰의 유효성을 검사하기 때문에 따로 DB가 팔요하지 않다. 대신 로그인 정보를 직접 저장해두지 않기 때문에 중복 로그인등의 요소에 대한 대처가 어렵다. |
※ 참고로 여기서 토큰은 https에서 사용한다.
토큰의 실제 사용
GitHub에서는 프로필 -> Settings -> Developer Settings -> Personal access tokens에서 토큰을 발급받을 수 있다.
깃허브에서는 두 가지 방식의 토큰을 생성한다. 하나는 Tokens(classic)이고 다른 하나는 Fine-grained tokens이다.
Tokens(classic)은 원래 PAT(Parsonal Access Tokens)로 불렸으며 Fine-grained tokens가 나오기 전에 사용되던 방식이다. 이 토큰은 허가받은 모든 저장소와 조직의 데이터를 관여할 수 있는 권한을 가지게 한다. 그래서 이러한 부분이 보완된 새로운 토큰인 Fine-grained tokens는 더 세분화된 권한을 사용자에게 부여할 수 있기 때문에 GitHub Docs에서는 후자의 방식을 권장하고 있다.
두 토큰 모두 만료일을 정하지 않을 수 있지만 11년 동안 사용하지 않은 parsonal access token(classic)의 경우 보안 조치로 자동 삭제되며, Fine-grained tokens 또한 조직에서 최대 수명 정책을 적용했을 경우 만료일 미지정이 차단될 수 있다.
git clone https://<토큰 내용>@github.com/사용자이름/저장소이름.git
위와 같이 토큰을 사용할 수 있다.
※ 만약 토큰을 적지 않고 일반적인 URL로 git clone을 진행할 경우 로그인을 하거나 토큰을 적는 페이지가 뜬다.
윈도우 자격 증명
윈도우에서는 한번 github에 로그인(아이디 패스워드이든 토큰이든)을 한 후 git clone을 토큰 기재 없이 진행할 경우 정상적으로 작동한다.
그 이유는 윈도우의 자격 증명 관리자를 보면 알 수 있다.
제어판 -> 사용자 계정 -> 자격 증명 관리자 -> Windows 자격증명
일반 자격 증명 항목에 git:https://github.com 이 있는 것을 볼 수 있다.
이는 저장소에 접근을 할 때 생성이 된다.(로그인 창이 떴을 때 로그인을 하거나 토큰을 통해 접근을 할 때)
이후에 git clone 등을 진행할 때 따로 토큰을 적지 않아도 해당 자격 증명에서 접근 자격을 증명해 주기 때문에 git clone이 정상적으로 진행된다.
git config를 통해 토큰을 더 편하게 사용
.gitconfig 파일에는 git에 대한 환경설정이 들어있다.
토큰을 통해 git clone을 진행할 때
https://<토큰>@github.com/사용자명/저장소이름.git위와 같이 토큰을 작성하게 된다.
이때 git config를 이용해서 특정 url을 다른 url로 치환할 수 있는 설정이 있다.
git config --global url.https://[토큰]@github.com/.insteadof https://github.com해당 설정은 https://github.com을 앞에 적은 url로 대신할 수 있는 설정이다.
이를 통해 토큰을 일일이 적지 않고 public 저장소에 접근하듯이 적어도 된다는 장점이 있다.
또한 뒤의 url을 https://github.com-me/ 등으로 바꾸어도 되기 때문에 .ssh의 config 파일에서 호스트명으로 사용할 키를 따로 설정하듯이 사용이 가능하다.
마무리
ssh에 이어 토큰을 조사해 보면서 https에 대해서 조사해 보는 계기가 되었다.
이를 통해 클라이언트와 서버간의 관계에 대해 더 궁금해지게 되었다.
또한 Private Repository를 clone 할 때 토큰을 적지 않았음에도 clone이 되는 이유가 윈도우 자격 증명 관리자 때문이라는 사실을 알게 되었고, ssh와 토큰을 알아보는 과정에서 git에 대한 공부도 필수다 보니 git을 활용하는 것이 처음보다 좋아졌음을 느끼게 되었다.