인가란
인증된 사용자에 대한 자원 접근 권한 확인
인증이란
식별가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정
<예시 : 게시판 서비스 >
회원이 글을 쓰기 위해서는 회원가입 후 로그인을 해야한다
-> 인증(로그인하는 과정)
글을 쓸 수 있는 권한 획득
다른 회원의 글을 읽기 O
다른 회원의 글 수정 X
-> 인가
*** HTTP속성 - 무상태성 (Stateless) : 상태를 유지하지 않는다
상태를 유지 하지 않기 때문에 클라이언트와 연결된 서버가 장애가 발생했더라도 클라이언트가 요청 정보를 기억하기 때문에 다른 서버를 연결하더라도 문제가 없다
→ 서버는 클라이언트가 보낸 요청과 그 다음 요청에 대한 연관관계가 없다라고 생각
인증하기 (Request Header)
사용자 https://www.tistory.com/login 접근 → https://HM:qwer!1234@www.tistory.com/login 로그인 요청 (API구축 환경)
요청 헤더
Authorization : Basic dQ3uZXk6vGDzsd4dwf
인증 유지하기 (Browser)
→ 문제점 : 사용자가 매번 로그인을 해줘야 한다.
→ 해결 : 쿠키사용 (쿠키에 ID,PW를 넣어 로그인 요청을 할 때마다 다시 보낸다) → 보안 취약
안전하게 인증하기 (Server)
Session 활용
세션은 인증된 사용자의 식별자와 랜덤한 문자열로 세션ID 생성 → 응답헤더에 넘겨줌 → 클라이언트가 저장
→ 장점 : 세션의 만료기간을 정해 만료기간이 지나면 해커가 정보를 탈취해도 유효하지 않다
→ 장점 : 세션은 서버에서 관리 -> 서버에서 삭제하면 세션 자체를 이용하지 못함(보안상 이점)
→ 문제점
위 그림에서 서버가 여러개 일 경우 서버 앞단에 로드밸런서를 하나 두게 된다
이 상황에서 사용자가 인증요청을 하면 위 그림과 같이 똑같이 세션을 받지만
만약 , 두번째 요청을 했을때 처음 요청을 보냈었던 서버가 아닌 다른 서버가 요청을 받는다면 문제가 발생한다!
그 이유는 서버 하나하나 자체에서 세션을 관리하고 있기 때문이다.
→ 해결 : 세션스토리지(저장소) 활용 - 서버들에 있는 모든 세션들을 한곳에서 관리
로드밸런서를 거쳐 각각 다른 서버에 요청이 와도 세션스토리지 한곳에 정보가 들어오기 때문에 해결
이것 또한 문제가 있다고 한다. 클라이언트(사용자)가 많은 경우 과부하!
*** 로드밸런서 : 여러 대의 서버를 두고 서비스를 제공하는 분산 처리 시스템에서 필요한 기술
작업(Work), 즉, 부하(Load)를 나누는 것
효율적으로 인증하기 (Token)
정보의 요청과 응답안에 사용자의 상태를 담아보자, 사용자의 인증과 인가를 처리하자
-> 토큰을 활용한 인증과 인가 방법
JWT(JSON WEB TOKEN)
인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰
JWT의 가장 핵심적인 부분은 시크릿 키에 대한 설정 -> 해당 값을 알아낸다면 토큰을 생성하고 변조 하여 악의적인 행동이 모두 가능해 진다.
즉, JWT 자체는 해독하기가 쉽다 -> 민감한 정보(비밀번호,..)를 담지 않는다
JWT의 인증 과정은 위 이미지를 참고 하면 된다!
아직, JWT의 내용이 헷갈리는 부분이 많아서 다음에 블로그로 자세하게 다뤄보도록 하겠다.
