노트

인증과 인가

Authentication and Authorization

백엔드#security · 연결된 개념 12개

쉽게 말하면

인증은 공연장 입구에서 표와 신분증으로 '누구인지' 확인하는 거고, 인가는 안에서 손목밴드 색을 보고 'VIP석에 들어가도 되는지' 판단하는 거예요. 확인이 먼저, 허락이 그다음이죠.

비유가 깨지는 곳 공연장은 입구만 지키면 될 것 같지만, 서버는 로그인한 사람이 남의 주문 ID로 조회하지 못하게 객체마다 소유를 확인해야 해요(IDOR). 버튼을 숨기는 건 인가가 아니고, 인가는 항상 서버에서 해요.

인증(authentication)은 "너는 누구냐"를 확인하는 것이고, 인가(authorization)는 "너는 이걸 해도 되냐"를 판단하는 것이다. 인증이 먼저고 인가가 그다음이다.

인증인가
질문누구인가무엇을 할 수 있는가
예로그인, 토큰 검증관리자만 삭제, 작성자만 수정
실패 응답401 Unauthorized403 Forbidden
근거비밀번호, 토큰, 키역할(role), 권한, 소유 관계
  • HTTP 상태 코드 이름이 헷갈리게 붙어 있다. 401의 이름은 Unauthorized지만 실제 뜻은 "인증이 안 됨"이고, 403이 "인증은 됐지만 권한 없음"이다
  • 인증 수단: 세션 쿠키(세션 인증), 토큰(JWT), API 키, SSH(Secure Shell) 키(SSH 키: Ed25519와 RSA)
  • 인가 수준: URL·메서드 단위(관리자 페이지), 객체 단위(내 글만 수정), 행 단위(행 수준 보안 (RLS))

프레임워크에서

  • 스프링 시큐리티: 필터체인의 인증 필터가 SecurityContext에 사용자를 채우고, 이후 hasRole·@PreAuthorize로 인가한다
  • DRF: authentication 클래스는 요청을 보낸 사용자가 누구인지 식별만 하고 요청을 막지 않는다. 허용 여부는 permission 클래스가 결정한다(DRF 인증과 권한)
  • Django: AuthenticationMiddleware가 request.user를 채운다(Django 미들웨어와 로그인 흐름)

흔한 실수

  • 인증만 확인하고 객체 소유를 확인하지 않아, 로그인한 누구나 남의 주문 ID로 조회할 수 있다(IDOR, Insecure Direct Object Reference)
  • 프론트엔드에서 버튼을 숨기는 것으로 인가를 대신한다. 인가는 항상 서버에서 한다(브라우저 요청과 서버 간 요청)
  • 403이어야 할 때 404를 돌려주면 리소스 존재 자체를 숨길 수 있다. 의도적으로 고른다

비밀번호를 안전하게 저장하는 문제는 비밀번호 저장: 인코딩·암호화·해싱을 본다.

출처: MDN: 401 Unauthorized · MDN: 403 Forbidden · OWASP Top 10:2025 A01: Broken Access Control

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • CSRF

    CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 로그인한 사용자가 악성 사이트를 방문했을 때, 그 사이트가 사용자의 브라우저를 시켜 사용자 모르게 원래 사이트에 요청을 보내게 하는 공격이다. 공격자는 토큰을 훔치지 않는다. 브라우저가 쿠키를 알아서 붙여 준다는 점을 이용한다.

  • Django의 CSRF 방어

    Django는 CsrfViewMiddleware로 CSRF(Cross-Site Request Forgery)를 막는다. 기본 아이디어는 Double Submit Cookie, 즉 쿠키에 든 CSRF 값과 요청에 함께 보낸 값을 비교하는 것이고, 여기에 토큰 마스킹(token masking)과 Origin·Referer 검사를 더한다.

  • XSS

    XSS(Cross-Site Scripting)는 공격자가 넣은 스크립트가 내 사이트의 출처(origin) 권한으로 사용자 브라우저에서 실행되는 공격이다. 같은 출처의 코드로 돌기 때문에 same-origin-policy가 막아 주지 못한다. 그 스크립트는 페이지를 바꾸고, 로그인한 사용자 행세를 하며 요청을 보내고, JS가 읽을 수 있는 데이터(localStorage의 토큰 등)를 빼 갈 수 있다.

  • 동일 출처 정책

    한 출처에서 실행된 스크립트가 다른 출처의 데이터를 읽지 못하게 막는 브라우저의 기본 보안 규칙. 다른 출처에 요청을 보내는 것은 대체로 허용하고, 응답을 읽는 것을 막는다.

  • DRF API 테스트

    DRF는 장고 테스트 위에 API 요청을 편하게 보내는 APITestCase와 APIClient를 제공한다. 장고 테스트 러너(test runner)는 테스트용 DB를 따로 만들고, 각 테스트를 트랜잭션으로 감싸 끝나면 되돌리므로 실제 데이터를 건드리지 않는다.

보기 옵션