인증과 인가

인증(Authentication) 이란?

사용자의 신원을 검증하는 행위, 해당 사용자가 누구인지 확인하는 절차

비밀번호, 일회용 핀, 인증 앱(외부기관), 생체인식 같은 인증 프로세스를 이용해서 시스템에 액세스 할 수 있는지 확인

인가(Authorization) 란?

사용자가 해당 request를 실행할 수 있는 권한이 있는 사용자인지를 확인하는 절차

시스템 보안에서 인가란, 사용자에게 특정 리소스나 기능에 액세스 할 수 있는 권한을 부여하는 프로세스

-> 권한이 있는지 확인하는 절차라는거야 아니면 권한을 부여하는 프로세스라는거야...?

 

보안환경에서 인가는 항상 인증 이후에 진행되어야 한다

HTTP의 Stateless

웹 사이트는 HTTP 통신 위에서 동작하고 따라서 웹 사이트 내의 모든 요청과 응답은 stateless 특성을 가진다

즉 서버에서 클라이언트의 이전 상태를 기억하고 있지 않음

-> 그렇다면 인증, 인가가 필요한 모든 상황에서 사용자는 자신을 인증해야 하잖아?

인증과 인가 구현 방식

Cookie

쿠키와 세션이 기억나지 않는다면

사용자가 로그인 할 때 서버는 ID와 PW를 쿠키에 담아 응답하고, 이후 요청부터는 브라우저가 해당 정보를 함께 담아 보낸다면 사용자는 매번 ID, PW를 입력할 필요가 사라짐

• 기존 로그인에 사용했던 정보를 그대로 사용하기 때문에 추가적인 데이터 저장이 필요하지 않음
• scale out에도 크게 문제가 발생하지 않음
• 사용자의 주요 정보를 매번 요청에 그대로 담아 보내기 때문에 보안상의 문제 발생
• 쿠키의 용량 제한으로 인해 많은 정보 전달 불가
• 브라우저마다 쿠키의 지원 형태가 달라 브라우저간 공유 불가능
• 쿠키의 사이즈가 커질수록 네트워크에 부하 발생

Session

서버 측에 정보를 저장하고 관리하는 세션을 이용한다면?

1. 사용자가 로그인 하면 서버에 세션과 세션ID가 생성이 된다

2. 해당 세션ID를 쿠키에 저장한다

3. 클라이언트에서 인증, 인가가 필요한 작업을 수행 할 때 세션ID가 저장된 쿠키를 같이 전송한다

4. 서버는 세션ID를 통해 세션을 찾아 필요한 요청을 수행한다

• 쿠키가 노출되어도 세션ID 자체는 유의미한 정보가 아니기 때문에 보안상 이점 존재
• 세션ID 또한 탈취 가능성 존재
• 사용자가 늘어나면 해당 유저의 정보를 찾고 데이터 매칭에 시간이 오래 걸림 -> 오버헤드 발생
• 서버에서 정보를 관리한다는 점이 stateless 특성과 거리가...

Token

기존 로그인 정보를 그대로 사용하지 않으면서 서버에서 사용자 식별 값을 저장, 관리 하지 않아도 되는 방법

-> TOKEN

 

사용자가 인증할 수 있는 정보가 숨겨진 암호화 된 Access Token을 발행하고, 인증이 필요할 때마다 서버에 Token과 함께 요청을 보내는 방식

 

1. 클라이언트가 서버에 접속하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 Token을 부여 (해당 토큰은 유일)

2. 클라이언트는 해당 Token을 쿠키 또는 스토리지에 저장

3. 서버에서 다시 요청이 오는 경우 요청 헤더에 해당 Token을 포함시켜 전달

4. 서버에서 클라이언트로 부터 받은 Token을 서버에서 제공한 Token과 일치 여부를 체크하여 인증 과정 처리

-> 토큰에는 요청한 사람의 정보가 담겨있기 때문에 서버는 DB 조회 없이 누가 요청했는지 확인 가능

 

서버는 저장된 데이터가 아닌 Token 해독을 통해 사용자를 식별할 수 있는 정보를 파악

• 인증 정보에 대한 별도의 저장소가 필요하지 않음 -> 서버 부하를 줄여줄 수 있다
• 한 번 발급되면 유효기간이 만료될 때까지 계속 사용 가능
• 토큰 자체의 데이터 길이가 길어 인증 요청이 많아지면 네트워크 부하가 심해짐
• Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없음
• 토큰을 탈취당하면 대처하기 어려움 -> 사용기간 제한을 통해 해결
• 특정 사용자의 접속을 강제로 만료하기 어려움

보안전략

1. 토큰 탈취를 방지하기 위해서 토큰 만료기간을 짧게 설정

-> 사용자가 자주 로그인 해야하는 불편함

2. Sliding Session

서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법

-> 토큰 만료기간이 짧을 때 자주 로그인 해야하는 단점 보완

3. Refresh Token

클라이언트가 로그인 요청을 보내면 서버는 Access Token과 그보다 만료기간이 긴 Refresh Token을 함께 제공

만약 Access Token만 만료된 경우 Refresh Token을 이용하여 Access Token 재발급을 요청하면 사용자가 새로 인증을 하지 않아도 된다