본문 바로가기
영상 후기/기타

영상 후기 - [10분 테코톡] 🎡토니의 인증과 인가

by 올리브영 2023. 4. 20.
728x90
반응형

movie

인증

  • (식별 가능한 정보로) 서비스에 등록된 유저의 신원을 입증하는 과정

인가

  • 인증된 사용자에 대한 자원 접근 권한 확인
  • 무조건 인증을 받았다고 해서 모든곳을 들어갈 수 없다.

웹에서의 인증과 인가

  • 로그인하는 과정을 인증
  • 로그인하는 동시에 인가 다양한 활동이 가능하다.
  • 그러나 남의 게시판은 수정을 못한다.
    • 그거에 대해서는 인가를 못받았기 때문이다.

인증과 인가의 사전 지식

  • 클라이언트와 서버는 HTTP를 통해 통신을 한다.
  • HTTP는 무상태성
    • 클라이언트 첫번째 요청과 두번째 요청은 연관관계가 없다.

 

1. 인증하기 - Request Header를 통해 간단하게 로그인 가능

로그인 상황

  • 사용자가 아이디와 비번을 앞에 달아주고 http://user:1q2w3e!@www.~~~~~/login를 요청하면 알아서 로그인 요청이 간다.(API가 구축이 되었을경우)
  • http://user:1q2w3e!@www.~~~~~/login는 브라우저가 처리를 해준다.
    1. 들어온 URL을 Base64라는 인코더를 이용해서 인코딩을 이용한 후에 전달해준다.
    2. user:1q2w3e! 파싱해서 인코터를 통해 인코딩을 한다.
    3. 인코딩한 값을 Request Header에서 Authorization에 넣어준다.
  • HTTP로 요청을 보내고 서버가 DB를 체크해서 DB에 값이 있으면 OK 응답을 보내준다.

Request Header만 활용할 시 문제점

  • 사용자가 매번 로그인을 해줘야 한다.
    • 지금과 같은 상황이라면 매번 인증을 해줘야 한다.

 

2. 인증 유지하기 - Browser의 Storeage 활용

  • 쿠키에 간단하게 사용자 아이디 비번을 넣는다.
  • 인증을 필요한 요청을 할때 같이 보내준다.
  • 그러면 클라이언트는 매번 로그인할 필요없이 원하는 자원을 받을 수 있다.

문제점

  • 그러나 스토리지에 사용자의 정보를 넣으면 해커입장에서도 편리하게 사용자 정보를 가져올 수 있어서 문제가 될 수 있다.
  • 클라이언트는 서버보다 상대적으로 보안에 취약하다.

 

3. 안전하게 인증하기 - Server의 Session 활용

  • 로그인을 하면 서버에서는 인증된 사용자의 식별자 랜덤한 문자인 SessionID를 만들어서 응답에 헤더로 넘겨준다.
  • 클라이언트가 저장을 할수있도록 만들어준다.
  • JESSIONID=asdfsadfsdasdf

장점

  1. 장점은 해커가 해당 정보를 가지고 가더라도 크게 위험하지 않다.
  2. 세션의 만료기간을 정할 수 있다. 
    • 만료기간이 지나면 그 세션아이디는 유효하지 않게된다.
  3. 세션의 관리를 서버가 하고 있어서 탈취가 된 세션을 서버에서 삭제하면 삭제된 세션은 이용하지 못하게 된다.

문제점

  • 서버를 여러개 두었을때 로드밸런서가 생기는데 3번째 서버에 요청을하고 응답으로 세션아이디를 받는다.
  • 그러나 2번째 서버에 헤더에 세션아이디를 같이 보내게 되면 2번째 서버는 해당 세션아이디를 갖고있지 않아서 에러가 발생.
  • 이 문제는 각 서버마다 자체적으로 관리하기 때문에 생긴 문제이다.

 

  • 그나마 서버에서 세션 스토리지를 하나 생성하면 이 문제를 피할 수 있긴하다.
  • 그러나 클라이언트가 너무 많아지면 해당 스토리지에 너무 많은 데이터가 저장되면서 스토리지가 터질 수 있다.

4. 효율적으로 인증하기 - 토큰을 활용

  • 초기에는 클라이언트나 서버에 사용자의 상태를 맡겼었는데, 문제점들이 발생하였다.
  • 그래서 이번에는 요청과 응답안에 사용자의 상태를 담을 것이다. 즉, 흐름에게 맡기는 방법을 사용.(TOKEN)

 

JWT

  • 시크릿 key를 사용해서 JWT를 만들어 낸다. 그리고 시크릿 key를 사용해서 JWT의 인증 과정을 거친다.
  • JWT 자체는 해독하기 쉽다. 그래서 JWT 내에는 민감한 정보를 대부분 담지 않는다.(비밀번호와 같은 것)
  • 시크릿 key가 중요한 만큼 노출되면 JWT 토큰 자체도 의미가 없어진다. 그래서 토큰을 사용하기 위해서는 시크릿 키를 서버 내부에 잘 관리를 해야한다.

JWT 과정

  1. 처음은 똑같이 로그인을 통해 요청을 보낸다.
  2. DB랑 체킹을 한다.
  3. 시크릿 키를 이용해서 토큰을 만들어낸다.
  4. 헤더에 해당 토큰을 넣어서 응답으로 보내준다.
  5. 다음부터는 해당 토큰을 이용해서 요청을 보내고 응답을 받는 형태가 된다.
  6. 클라이언트는 다음 요청때 토큰을 통해 서버에 요청을 한다.
  7. 서버는 토큰의 유효성 검사를 본인이 가진 시크릿key로 진행을 한다.(통과되면 인증을 받은 토큰)
  8. 유효하지 않다면 버리고, 유효하다면 다음 단계인 사용자정보를 파악을 한다.
  9. 디코딩을 통해서 사용자 정보에서 이름을 꺼내서 그 이름으로 어떤 유저인지 찾는다.
  10. 사용자 정보에서 만료시기를 꺼내서 만료시기를 알수있다.(만료되었다면 그토큰은 더이상 진행되지 않음)
  11. 사용자 정보에서 권한을 꺼내서 "이 사용자는 어드민이네?"라는 권한까지도 알 수 있다.
  12. 즉, 토큰 하나에서 다 확인할 수 있게 된다.
  13. 그렇지만 비밀번호 같은 정보는 담으면 안된다.(비밀번호는 디코딩하기 쉬워서 노출될 수 있다.)

장점

  • 서버가 여러대일 때, 세션에서는 세션 디비를 따로 두어서 세션디비와 연관성이 있었는데, 이제는 로드밸런서가 쏘는 것을 각자 자기가 가진 키로 해독을 해서 인증을 진행하면 된다.
  • 그리고 요청을 반환하면 되는 장점이 있다.
  • 더 나아가서 현대의 서버 시스템의 중요한 확장성과도 연결이 된다.
    • 3대였던 서버가 5대가 되어도 아까와 똑같이 진행가능
    • 각자 해독을해서 인증을 할수있다.

문제점

  • 액세스 토큰이 탈취당하면 사용자와 똑같은 지위를 갖게 된다.

문제점을 해결하기 위한 수단(Refresh Token)

  • 토큰 만료 기한을 정한다.
    • 만료기한 30분이 지나면 해커도 사용할 수 없고, 사용자도 사용할 수 없게 된다.
  • 이때, Refresh Token이 활용된다.

Refresh Token

  1. 처음과 똑같이 사용자는 로그인 요청을 보낸다.
  2. 서버는 보낸 로그인 요청에 따라 시크릿 키를 통해서 토큰을 만든다.
  3. 이때 서버가 만든 토큰은 Access 토큰과 Refresh 토큰을 한번에 만들어 낸다.
  4. 서버는 Access토큰은 저장하지 않고 Refresh토큰만 따로 저장소에 저장을 하게 된다.
  5. 두개의 토큰 한번에 응답헤더에 보내서 클라이언트가 두 토큰을 저장하게 된다.
  6. 만약 클라이언트가  Access토큰이 만료된지도 모르고 요청을 보내게 되면
  7. 서버는 만료가 되었다고 클라이언트에게 응답을 준다.
  8. 브라우저에서는 자동으로 Access토큰과 Refresh토큰을 함께 다시 서버로 보내게된다.
  9. 서버는 돌아온 Refresh토큰을 참고해서 DB를 찔러서 만약 맞다면 새로 갱신한 액세스 토큰을 클라이언트에게 보낸다.
  10. 그러면 클라이언트는 업데이트 된 액세스 토큰을 사용할 수 있게된다.

토큰 활용하기 - 핵심

  • 토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다.
    • 효율성이 좋아지고 DB를 찔러도 되지 않아서 속도가 빠르다는 장점
  • 토큰 관리를 해야한다. 결국 토큰도 탈취당할 수 있다.
728x90
반응형