728x90
반응형
인증
- (식별 가능한 정보로) 서비스에 등록된 유저의 신원을 입증하는 과정
인가
- 인증된 사용자에 대한 자원 접근 권한 확인
- 무조건 인증을 받았다고 해서 모든곳을 들어갈 수 없다.
웹에서의 인증과 인가
- 로그인하는 과정을 인증
- 로그인하는 동시에 인가 다양한 활동이 가능하다.
- 그러나 남의 게시판은 수정을 못한다.
- 그거에 대해서는 인가를 못받았기 때문이다.
인증과 인가의 사전 지식
- 클라이언트와 서버는 HTTP를 통해 통신을 한다.
- HTTP는 무상태성
- 클라이언트 첫번째 요청과 두번째 요청은 연관관계가 없다.
1. 인증하기 - Request Header를 통해 간단하게 로그인 가능
로그인 상황
- 사용자가 아이디와 비번을 앞에 달아주고 http://user:1q2w3e!@www.~~~~~/login를 요청하면 알아서 로그인 요청이 간다.(API가 구축이 되었을경우)
- http://user:1q2w3e!@www.~~~~~/login는 브라우저가 처리를 해준다.
- 들어온 URL을 Base64라는 인코더를 이용해서 인코딩을 이용한 후에 전달해준다.
- user:1q2w3e! 파싱해서 인코터를 통해 인코딩을 한다.
- 인코딩한 값을 Request Header에서 Authorization에 넣어준다.
- HTTP로 요청을 보내고 서버가 DB를 체크해서 DB에 값이 있으면 OK 응답을 보내준다.
Request Header만 활용할 시 문제점
- 사용자가 매번 로그인을 해줘야 한다.
- 지금과 같은 상황이라면 매번 인증을 해줘야 한다.
2. 인증 유지하기 - Browser의 Storeage 활용
- 쿠키에 간단하게 사용자 아이디 비번을 넣는다.
- 인증을 필요한 요청을 할때 같이 보내준다.
- 그러면 클라이언트는 매번 로그인할 필요없이 원하는 자원을 받을 수 있다.
문제점
- 그러나 스토리지에 사용자의 정보를 넣으면 해커입장에서도 편리하게 사용자 정보를 가져올 수 있어서 문제가 될 수 있다.
- 클라이언트는 서버보다 상대적으로 보안에 취약하다.
3. 안전하게 인증하기 - Server의 Session 활용
- 로그인을 하면 서버에서는 인증된 사용자의 식별자와 랜덤한 문자인 SessionID를 만들어서 응답에 헤더로 넘겨준다.
- 클라이언트가 저장을 할수있도록 만들어준다.
- JESSIONID=asdfsadfsdasdf
장점
- 장점은 해커가 해당 정보를 가지고 가더라도 크게 위험하지 않다.
- 세션의 만료기간을 정할 수 있다.
- 만료기간이 지나면 그 세션아이디는 유효하지 않게된다.
- 세션의 관리를 서버가 하고 있어서 탈취가 된 세션을 서버에서 삭제하면 삭제된 세션은 이용하지 못하게 된다.
문제점
- 서버를 여러개 두었을때 로드밸런서가 생기는데 3번째 서버에 요청을하고 응답으로 세션아이디를 받는다.
- 그러나 2번째 서버에 헤더에 세션아이디를 같이 보내게 되면 2번째 서버는 해당 세션아이디를 갖고있지 않아서 에러가 발생.
- 이 문제는 각 서버마다 자체적으로 관리하기 때문에 생긴 문제이다.
- 그나마 서버에서 세션 스토리지를 하나 생성하면 이 문제를 피할 수 있긴하다.
- 그러나 클라이언트가 너무 많아지면 해당 스토리지에 너무 많은 데이터가 저장되면서 스토리지가 터질 수 있다.
4. 효율적으로 인증하기 - 토큰을 활용
- 초기에는 클라이언트나 서버에 사용자의 상태를 맡겼었는데, 문제점들이 발생하였다.
- 그래서 이번에는 요청과 응답안에 사용자의 상태를 담을 것이다. 즉, 흐름에게 맡기는 방법을 사용.(TOKEN)
JWT
- 시크릿 key를 사용해서 JWT를 만들어 낸다. 그리고 시크릿 key를 사용해서 JWT의 인증 과정을 거친다.
- JWT 자체는 해독하기 쉽다. 그래서 JWT 내에는 민감한 정보를 대부분 담지 않는다.(비밀번호와 같은 것)
- 시크릿 key가 중요한 만큼 노출되면 JWT 토큰 자체도 의미가 없어진다. 그래서 토큰을 사용하기 위해서는 시크릿 키를 서버 내부에 잘 관리를 해야한다.
JWT 과정
- 처음은 똑같이 로그인을 통해 요청을 보낸다.
- DB랑 체킹을 한다.
- 시크릿 키를 이용해서 토큰을 만들어낸다.
- 헤더에 해당 토큰을 넣어서 응답으로 보내준다.
- 다음부터는 해당 토큰을 이용해서 요청을 보내고 응답을 받는 형태가 된다.
- 클라이언트는 다음 요청때 토큰을 통해 서버에 요청을 한다.
- 서버는 토큰의 유효성 검사를 본인이 가진 시크릿key로 진행을 한다.(통과되면 인증을 받은 토큰)
- 유효하지 않다면 버리고, 유효하다면 다음 단계인 사용자정보를 파악을 한다.
- 디코딩을 통해서 사용자 정보에서 이름을 꺼내서 그 이름으로 어떤 유저인지 찾는다.
- 사용자 정보에서 만료시기를 꺼내서 만료시기를 알수있다.(만료되었다면 그토큰은 더이상 진행되지 않음)
- 사용자 정보에서 권한을 꺼내서 "이 사용자는 어드민이네?"라는 권한까지도 알 수 있다.
- 즉, 토큰 하나에서 다 확인할 수 있게 된다.
- 그렇지만 비밀번호 같은 정보는 담으면 안된다.(비밀번호는 디코딩하기 쉬워서 노출될 수 있다.)
장점
- 서버가 여러대일 때, 세션에서는 세션 디비를 따로 두어서 세션디비와 연관성이 있었는데, 이제는 로드밸런서가 쏘는 것을 각자 자기가 가진 키로 해독을 해서 인증을 진행하면 된다.
- 그리고 요청을 반환하면 되는 장점이 있다.
- 더 나아가서 현대의 서버 시스템의 중요한 확장성과도 연결이 된다.
- 3대였던 서버가 5대가 되어도 아까와 똑같이 진행가능
- 각자 해독을해서 인증을 할수있다.
문제점
- 액세스 토큰이 탈취당하면 사용자와 똑같은 지위를 갖게 된다.
문제점을 해결하기 위한 수단(Refresh Token)
- 토큰 만료 기한을 정한다.
- 만료기한 30분이 지나면 해커도 사용할 수 없고, 사용자도 사용할 수 없게 된다.
- 이때, Refresh Token이 활용된다.
Refresh Token
- 처음과 똑같이 사용자는 로그인 요청을 보낸다.
- 서버는 보낸 로그인 요청에 따라 시크릿 키를 통해서 토큰을 만든다.
- 이때 서버가 만든 토큰은 Access 토큰과 Refresh 토큰을 한번에 만들어 낸다.
- 서버는 Access토큰은 저장하지 않고 Refresh토큰만 따로 저장소에 저장을 하게 된다.
- 두개의 토큰 한번에 응답헤더에 보내서 클라이언트가 두 토큰을 저장하게 된다.
- 만약 클라이언트가 Access토큰이 만료된지도 모르고 요청을 보내게 되면
- 서버는 만료가 되었다고 클라이언트에게 응답을 준다.
- 브라우저에서는 자동으로 Access토큰과 Refresh토큰을 함께 다시 서버로 보내게된다.
- 서버는 돌아온 Refresh토큰을 참고해서 DB를 찔러서 만약 맞다면 새로 갱신한 액세스 토큰을 클라이언트에게 보낸다.
- 그러면 클라이언트는 업데이트 된 액세스 토큰을 사용할 수 있게된다.
토큰 활용하기 - 핵심
- 토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다.
- 효율성이 좋아지고 DB를 찔러도 되지 않아서 속도가 빠르다는 장점
- 토큰 관리를 해야한다. 결국 토큰도 탈취당할 수 있다.
728x90
반응형
'영상 후기 > 기타' 카테고리의 다른 글
영상 후기 - [10분 테코톡] 🤠루피의 인증과 인가 (0) | 2023.04.28 |
---|---|
영상 후기 - [10분 테코톡] 📍인비의 DTO vs VO (0) | 2023.04.24 |
영상 후기 - 기계들의 대화법 - REST API (0) | 2023.04.18 |
영상 후기 - [10분 테코톡] 차리의 Stream (0) | 2023.03.17 |
영상 후기 - [10분 테코톡] 🙆♀️티버의 API vs Library vs Framework (0) | 2023.03.16 |