인증과 인가

이은지·2023년 12월 30일

🔆인증과 인가

인증(Authentication): 사용자의 신원을 확인하는 절차
인가(Authorization): 사용자의 권한을 확인하고 허가하는 절차(인가는 인증 절차를 거친 후에 진행됨)

🔆인터넷 환경의 인증, 인가

Request와 Response로 구성된 HTTP통신은 무상태성(Stateless)을 가짐
- HTTP 통신에서 서버는 현재요청과 이전요청의 맥락을 기억하지 못함
무상태성을 해결하기 위해 정보를 담은 url로 HTTP 통신을 진행
- 문제 1. 개인정보가 담긴 URL
- 문제 2. 서버 부하 가중(각 URL에 해당하는 HTML페이지 생성)
- 문제 3. 다른 사이트 이동, 로그아웃 시 기존의 데이터 삭제
해당 url 문제를 해결하기 위해 IP 주소 식별 방식이 등장함
- 서버는 클라이언트의 IP를 TCP커넥션 또는 HTTP 헤더를 통해 알 수 있음
- 문제 1. 클라이언트 IP는 사람이 아닌 컴퓨터의 식별자
- 문제 2. 많은 인터넷 서비스 제공자(ISP)는 동적으로 IP주소를 할당하여 IP주소는 바뀔 수 있음
- 문제 3. 방화벽, 프록시, 게이트웨이 등으로 인해 실제 클라이언트의 IP주소를 알기 어려움
HTTP 기본 인증 방식
- 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식
- 재전송 공격을 예방하지 못함
- 가짜 서버의 위장에 취약함

🔆 쿠키와 세션을 통한 인증

쿠키, 세션 용어정리
- 쿠키
  - 브라우저에 저장되는 키와 값이 들어있는 데이터 파일
  - 클라이언트의 상태 정보를 저장
  - 사용자가 따로 요청하지 않아도 Request시 Header에 담겨 서버에 전송
- 세션
  - 쿠키와 달리 서버 측에서 관리
  - 클라이언트를 구분하기 위해 세션 ID 부여
  - 세션 ID를 통해 클라이언트 식별
인증 과정

클라이언트가 username가 password 데이터를 담아 유저 로그인을 요청
서버는 해당 username과 password로 서버에 인증된 회원인지 확인을 하고, 세션 ID를 생성하고, 세션 ID를 쿠키에 담아 클라이언트에게 보냄
클라이언트는 쿠키를 가지고 있다가 다음 요청 때 세션ID가 담긴 쿠키와 함께 요청
서버는 쿠키에 담긴 세션 ID와 세션 저장소에 담긴 세션 ID를 비교해서 사용자의 인가 여부를 결정

문제점

쿠키와 세션을 통한 인증은 다중 서버 환경에서의 세션 불일치 문제가 발생할 수 있음 하나의 서버에서는 인증이 되었고, 하나의 서버에서는 인증이 안됬다면, 세션 불일치 문제가 발생할 수 있다

해결 방법
- Sticky Session
  - 로드밸런서가 클라이언트 요청을 세션을 생성한 서버만 전달
- Session Clustering
  - 모든 서버의 세션 동기화
- 별도의 세션 저장소 생성
  - Redis, Memached 등

이러한 해결방법이 있지만, 근본적으로 확장성이 떨어진다는 문제는 해결하지 못함

🔆 JWT 토큰 기반 인증 방식

JWT 용어 정리
- Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token
- 인증에 필요한 정보들을 암호화 시킨 JSON 토큰
JWT의 구조
- Header
  - 토큰의 타입
  - 해싱 알고리즘
- Payload
  - Claims(사용자의 정보가 담겨 있음)
- Signature
  - header, payload를 합친 문자열을 서버의 비밀키와 함께 서명(암호화)한 값

인증 과정

클라이언트에서 username, password와 함께 유저 로그인을 요청
서버는 해당 로그인 된 유저를 인증 절차를 거치고 클라이언트에게 토큰을 발급
클라이언트는 가지고 있다가 Authorization 헤더에 해당 토큰을 가지고 다시 요청
서버에서는 해당 비밀키로 무결성을 검증한 후에 토큰의 유효성을 검증하고 유저를 인가

특징
- 서버 기반 인증 시스템과 달리 상태를 유지하지 않는다(Stateless)
- DB를 조회하지 않고 인증된 회원인지 식별할 수 있다
단점
- 쿠키, 세션과 다르게 토큰 자체의 데이터 길이가 길다
- payload는 암호화되지 않기 때문에 유저의 중요한 정보를 담을 수 없다
- 토큰을 탈취 당하면 대처하기 어렵다

🔆소셜 로그인의 등장

소셜로그인은 OAuth와 OpenID를 통해 구현이 가능하다

❗ OAuth는 인가에 대한 기술이고, OpenID는 인증에 대한 기술!

1. OAuth

웹, 모바일, 데스크톱 어플리케이션에서의 간단하고 표준적인 방법으로 보안 인가를 허용하기 위한 개방형 표준 프로토콜
OAuth의 주체
- Resource Owner(예: 사용자)
  - 리소스를 소유하며 접근할 권한을 가지고 있고, 클라이언트에게 그 권한을 위임하는 주체
- Client(예: 구글 소셜로그인을 도입하려는 웹사이트)
  - 리소스 소유자 대신 위임 받은 권한으로 리소스를 요청하는 주체
- Authorization Server, Resource Server(예: 구글)
  - Authorization Server: 리소스 소유자를 인증하고 클라이언트에 액세스 토큰을 발급하는 서버
  - Resource Server: 액세스 토큰을 사용하여 리소스 요청을 수락하고 응답할 수 있는 리소스를 가지고 있는 서버
OAuth 2.0 동작 과정
1. 리소스 Owner는 ‘소셜로그인’을 클릭하여 로그인을 요청함
2. Client는 Client ID, Redirect URI, Response Type, Scope를 함께 전달하여 Authorization Server에 OAuth 인증 요청
  - Scope란? 클라이언트에게 허용된 리소스 접근 범위
3. Authorization Server는 Resource Owner에게 로그인 페이지를 제공
4. Resource Owner는 해당 페이지에서 로그인을 하게되고, ID, PW 등 인증 정보를 Authorization Server에 전달
5. Authorization Server를 통해 인증 코드가 발급되고 사용자는 Redirect URI로 리디렉션
6. 클라이언트는 방금 받은 Authorization Code를 통해서 Authorization Server에 Access Token 발급 요청
7. Access Token 발급을 받으면 해당 Access Token을 저장하고 Resource Owner에게 로그인이 성공 되었음을 알려줌

2. OpenID

등장 배경
- 사용자가 서비스마다 아이디와 패스워드를 외우려면 매우 불편함
- 신뢰할 수 있는 서비스(구글, 트위터 등)에 사용자 인증 절차를 위임 하고 사용자는 자기가 신뢰할 수 있는 서비스의 인증 정보 하나로 여러 웹사이트에서 로그인 할 수 없을까?
OpenID
- 비영리 기관인 OpenID Foundation에서 추진하는 개방형 표준 및 분산 인증 프로토콜
- 새 비밀번호를 만들 필요 없이 기존 계정을 사용하여 여러 웹사이트에 로그인할 수 있음
OpenID의 주체
- IdP(Identity Provider)
  - 구글, 카카오와 같이 OpenID 서비스를 제공하는 당사자
- RP(Relying Party)
  - 사용자를 인증하기 위해 IdP에 의존하는 주체
OpenID Connect(3세대 OpenID)
- OAuth2.0와 OpenID Connect 목적차이
  - OAuth2.0 목적: Access Token을 발급 받고, 그 Access Token을 통해서 리소스에 접근하기 위해 사용됨
  - OpenID Connect는 ID Token을 발급 받고, 그 ID Token으로부터 사용자 식별 정보를 얻기 위해 사용됨

ID Token
- 사용자 식별 정보를 담고 있는 토큰
- JWT 형식으로 표현
- ID Token의 payload에는 기본 클레임 외에 사용자를 식별할 수 있는 클레임이 추가적으로 들어있음
ID Token 발급 방법
- Client가 Authorization Server로 OAuth 2.0 인증 요청을 할 때, Scope에 openid를 추가하면 ID Token을 받을 수 있음