인증 vs. 인가: 무엇이 다른가?

인증은 사용자가 누구인지 확인하는 검사이고, 인가는 요청마다 무엇을 할 수 있는지 판단하는 결정으로, 안전한 시스템에는 둘 다 필수입니다. 호텔이 이를 구체적으로 보여 줍니다. 프런트에서 제시하는 신분증이 인증이고, 412호를 여는, 그리고 412호만 여는 키카드가 인가(권한 부여)입니다. 둘은 서로 다른 질문이며, 서로 다른 시점에 제기되고, 서로 다른 장치가 답하며, 서로 다른 방식으로 실패합니다. 둘을 뭉뚱그리는 시스템이 두 종류의 침해를 모두 겪는 이유입니다.

핵심 요약

하나의 요청에서 인증과 인가가 실행되는 방식

1  POST /login  (자격 증명 + MFA)            ── 인증, 한 번
   ← 세션 토큰 / 쿠키: 신원 확립

2  GET /documents/xKd91m                     ── 이후의 모든 요청:
   a · 토큰 검증           → 신원 재확립                     (인증 장치)
   b · 권한 평가           → ADA가 이 문서를 읽어도 되는가?  (인가 결정)

   → 200  둘 다 통과
   → 401  토큰 없음/무효 – WWW-Authenticate 챌린지; 로그인하면 해결됨
   → 403  토큰은 유효, 권한 거부 – 다시 로그인해도 달라지는 것 없음
   → 404  일부 API는 금지된 객체를 아예 숨김 (RFC 9110이 허용)

애플리케이션 코드에서의 같은 분리입니다. 로그인은 한 번, 판정은 작업마다 받습니다:

// JavaScript / Node.js — Back4app JS SDK
// Authentication: once — who are you?
const user = await Parse.User.logIn('ada', password); // session token issued

// Authorization: every request — may YOU do THIS?
const doc = await new Parse.Query('Document').get('xKd91m');
// found if an ACL entry grants ada read · "not found" if not

doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// Flutter / Dart — Back4app Flutter SDK
// Authentication: once — who are you?
final user = ParseUser('ada', password, null);
await user.login(); // session token issued

// Authorization: every request — may YOU do THIS?
final response = await QueryBuilder<ParseObject>(ParseObject('Document'))
    .query(); // returns only rows whose ACLs grant ada read

final doc = response.results!.first as ParseObject;
doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// iOS / Swift — Back4app Swift SDK
// Authentication: once — who are you?
let user = try await User.login(username: "ada", password: password)
// session token issued

// Authorization: every request — may YOU do THIS?
guard var doc = try await Document.query("objectId" == "xKd91m").first()
else { return } // found only if an ACL entry grants ada read

doc.title = "Renamed"
_ = try await doc.save() // succeeds only if an entry grants ada WRITE

// Android / Kotlin — Back4app Android SDK
// Authentication: once — who are you?
val user = ParseUser.logIn("ada", password) // session token issued

// Authorization: every request — may YOU do THIS?
val doc = ParseQuery.getQuery<ParseObject>("Document").get("xKd91m")
// found if an ACL entry grants ada read · "not found" if not

doc.put("title", "Renamed")
doc.save() // succeeds only if an entry grants ada WRITE

인증 vs. 인가, 나란히 비교

두 행에는 각주가 필요합니다. 실행 위치: 인증은 자연스럽게 경계부에 집중됩니다. 로그인 흐름 하나, ID 공급자(IdP) 하나입니다. 반면 인가는 보호하는 데이터 옆에 있어야 합니다. “이 사용자가 이 객체를 만져도 되는가”에 답하려면 그 객체가 필요하기 때문입니다. 실패 형태: 위협 모델이 서로 겹치지 않습니다. 크리덴셜 스터핑과 피싱은 인증을 공격하며(MFA가 가장 효과적인 인증 방어 수단인 이유입니다), 객체 수준 인가 취약점(BOLA)은 대표적인 인가 실패로 API 보안 목록의 최상위를 차지합니다. 로그인한 사용자, 엉뚱한 객체, 아무도 확인하지 않은 상황입니다.

401과 403, 정확하게

상태 코드는 이 구분에 숫자를 입힌 것이며, RFC 9110은 이를 정확하게 규정합니다. 401 Unauthorized는 역사상 가장 오래 살아남은 잘못된 이름입니다. 실제 의미는 미인증으로, 요청에 “유효한 인증 자격 증명이 없다”는 뜻이며, 응답에는 WWW-Authenticate 챌린지가 실려야 하고, 자격 증명을 제시하면 해결될 수 있습니다. 403 Forbidden은 서버가 누가 요청했는지 정확히 알면서도 거부한다는 뜻입니다. 정의상 다시 인증해도 소용이 없습니다. 그리고 명세는 보안 팀이 선호하는 세 번째 선택지도 허용합니다. 403 대신 404로 답하여, 금지된 리소스가 자신의 존재를 확인해 주지 않게 하는 것입니다. 코드를 올바르게 쓰는 것은 현학이 아닙니다. 클라이언트는 이 코드 위에 재시도와 재로그인 로직을 구축하며, 401이어야 할 자리의 403은 사용자를 로그인 폼 대신 벽으로 보냅니다.

OAuth, OIDC, 그리고 끝없는 혼동

이 혼동에 대한 답은 명세에 있습니다. OAuth 2.0의 제목은 “The OAuth 2.0 Authorization Framework”입니다. 범위가 지정된 권한을 옮기는 프레임워크이며, OpenID Connect 명세는 OAuth만으로는 “최종 사용자의 인증에 관한 정보를 제공할 수 없기” 때문에 존재합니다. OIDC는 신원 계층을 더합니다. 누가 인증했는가를 단언하는 ID 토큰으로, 소지자가 무엇을 할 수 있는가를 단언하는 액세스 토큰과는 구별됩니다. 모든 ”…로 로그인” 버튼은 OAuth의 인가 배관 위에서 OIDC가 인증을 수행하는 것입니다. 하나의 흐름에 두 개념이 혼동되지 않고 깔끔하게 층을 이룹니다.

프로덕션에 배포되는 세 가지 실수

클라이언트 측 인가. 삭제 버튼을 숨기는 것은 인터페이스 설계이고, 삭제가 실행될지를 서버가 결정하는 것이 보안입니다. OWASP에 따르면 기본적으로 거부하고, 서버 측에서 강제하며, 클라이언트 검사는 UX 힌트로 취급해야 합니다. 로그인 ≠ 허용. 인증은 확인하지만 객체 소유권은 확인하지 않는 것, 즉 /documents/42를 유효한 세션이라면 누구에게나 제공하는 것이 객체 수준 인가 취약점이며, 가장 흔한 API 취약점 유형입니다. 검사는 객체마다, 요청마다, 예외 없이 이루어져야 합니다. 미들웨어 순서. 개념에서처럼 코드에서도 인증이 먼저, 인가가 그 다음입니다. 신원 미들웨어가 누구인지를 확립한 뒤 핸들러가 허용되는지를 묻습니다. 신원이 확립되기 전에 실행되는 인가 검사는 익명 사용자를 소리 없이 인가합니다.

일반적인 사용 사례

• 앱 로그인 + 데이터 권한 – 일상적인 조합입니다. 인증 흐름 하나, 그 뒤의 모든 것에 객체별 규칙.
• API 설계 – 계약의 오류 언어로서의 401/403 의미론, 범위가 지정된 토큰, 객체 수준 검사.
• 멀티테넌트 SaaS – 인증은 테넌트 간에 공유되고, 인가는 각 테넌트 안에서 엄격하게 범위가 지정됩니다.
• 관리자와 지원 도구 – 단계적 인증과 상승된 인가, 의도적으로 분리된 두 이벤트.
• 공개 + 비공개 콘텐츠 – 인가 규칙으로서의 익명 읽기는 두 개념이 독립적으로 동작함을 증명합니다.

어떤 검사가 빠져 있을까? 결정 매트릭스

한계와 트레이드오프

• 분리는 개념적인 것이지 항상 아키텍처적인 것은 아닙니다. 작은 앱이 둘을 하나의 미들웨어 스택에서 실행하는 것은 합리적입니다. 규율은 검사를 구분하는 데 있지 서버를 나누는 데 있지 않습니다.
• 강한 인증이 약한 인가를 구하지 못합니다. 패스키와 MFA가 신원을 완벽하게 검증해도, 그 뒤에 누구나 무엇이든 읽게 두는 시스템이라면 소용이 없습니다. 두 실패는 독립적입니다.
• 요청마다 수행하는 인가에는 비용이 있습니다. 결정 캐싱, 규칙을 데이터 계층으로 내리기, 권한 인덱싱이 “모든 것을 검사”를 빠르게 유지하는 방법입니다.
• 단계적 인증은 시간축을 흐립니다. 민감한 동작은 세션 중간에 다시 인증합니다. 인증은 엄밀히 “한 번”이 아니라 “보증 수준당 한 번”입니다.
• 용어의 혼용은 실제 버그를 낳습니다. 두 절반을 모두 “auth”라고 부르는 팀은 둘을 뒤섞은 티켓, 테스트, 오류 코드를 작성합니다. 정확한 단어가 가장 저렴한 방어입니다.

Back4app에서의 인증과 인가

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 플랫폼의 아키텍처 자체가 이 분리입니다. User 클래스, 세션, 소셜 로그인, MFA 어댑터가 누구인지에 답하며 폐기 가능한 세션 토큰을 만들고, 그 뒤 ACL, 클래스 수준 권한, 역할이 무엇을 할 수 있는지에 답하며, 모든 REST, GraphQL, Live Query 요청마다 서버 측에서 평가됩니다. 코드 탭이 보여 주는 그대로, 로그인은 한 번, 판정은 작업마다입니다. 실수 섹션은 구조적으로 해결됩니다. Back4app이 API 뒤에서 인가를 강제하므로 인가는 클라이언트 측에 있을 수 없고, 인가되지 않은 객체는 존재 여부를 드러내는 대신 ‘찾을 수 없음’(not found)으로 응답되며, 기본 거부는 클래스의 체크박스 하나입니다. 플랫폼이 두 질문을 결코 합쳐지게 두지 않으므로 둘은 분리된 채로 남습니다.