인증(Authentication),인가(Authorization)

 

Reservatiom System

개요

예약시스템은 누구나 이용할 수 있는 서비스가 아니다.
그러니 신원이 확인된 사람에게만 Response를 해줘야하는 권한 체계가 필요하다. 
가장 익숙한 플로우인 로그인이 바로 그것이다. 
로그인을 하게되면 인증을 받게되고, 인증을 완료하면 "나 인증된 유저에요" 라는 일종의 "증표"가 필요하다. 
이제 인증과 인가에 대해서 알아보자 .

💡 인증(Authentication) " 식별 가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정 " 
💡 인가(Authorization) " 인증된 사용자에 대하여 자원의 접근권한을 확인하는 것 "

예약시스템은 모든 사용자가 페이지에 접속은 할 수 있지만, 예약을 하려면 유저 정보가 필요하다 
사용자는 로그인을 통해 서비스에 등록된 유저임을 서버에 알림과 동시에 기능을 호출할 수 있는 권한을 획득해야한다.

다시 정리하면 , 로그인을 통해 인증(Authentication), 서버로 부터 접근 권한을 인가(Authorization) 받아야한다.

유저는 자신의 예약에 대해서 수정, 삭제 할 수 있음 But, 다른 사람의 예약은 수정, 삭제 할 권한이 없음

즉, 인증과 인가란 웹 서비스에서 리소스를 적절한 사용자에게 전달 하고 공개하는 방법임

 

인증과 인가의 상호작용

1. 사용자는 로그인을 통해 인증(Authentication) 을 수행한다.
2. 인증이 성공하면 서버는 인가(Authorization) 에 필요한 인증 증표(Token) 를 발급한다.
3. 이후 사용자가 API를 호출할 때마다, 이 토큰을 통해 “나 인증된 사용자야”라고 증명한다.
   ex) Authorization: Bearer {JWT} 헤더를 포함해 요청
4. 서버는 토큰의 유효성을 검사한 뒤, 해당 요청이 허용된 범위인지 판단하여 처리한다.

세션 탈취의 문제

여기서 중요한 포인트는, 이 인증 증표(Token) 가 탈취될 수도 있다는 것이다.

즉, 권한 없는 사용자가  권한 있는 사용자의 토큰을 훔쳐서
“나 인증된 사용자야~” 라고 서버에 들이밀면, 서버는 그걸 진짜 나라고 착각하기 때문이다. 

그래서 토큰에는 반드시 유효기간 을 두어 기간이 지나면 무효한 토큰이 되게 한다.
그럼 다시 새로 토큰을 발급받게 만들어 권한 있는 사용자인지 다시 인증 받게 만든다. (물론, 또 탈취당하면 노답임)

그럼 하이재킹 당하지 않은 정상적인 사용자들도, 이런 위험때문에 위 오버헤드를 감당해야할까? 

당연히 아니다.
그래서 등장한 게 바로 "Access Token & Refresh Token 구조" 다.

Access Token & Refresh Token 구조

위 유효 매커니즘을 효율적으로 관리하기 위해 두 가지 유형의 토큰을 사용한다. 

종류	역할	유효기간
Access Token	API 호출 시 인증용 (Bearer + JWT)	짧다.
Refresh Token	Access Token 재발급용	길다.

두 가지 유형의 토큰이 작동하는 매커니즘은 다음과 같다. 

1. 로그인 성공 시 → Access Token + Refresh Token 발급
2. Access Token 만료 → Refresh Token으로 재발급 요청
3. 새 Access Token으로 다시 API 호출

 

즉, 모든 입장권이 만료될 때마다 로그인할 필요는 없고,

Refresh Token 덕분에 Access Token만 재발급받아서 계속 서비스 이용이 가능하다.

이 구조 덕분에, 보안성은 유지하면서도 정상 사용자의 UX는 최대한 깔끔하게 유지할 수 있다.