로그인 화면 하나에 비밀번호, OTP, 소셜 로그인, SSO가 함께 등장하면 모든 기술을 “인증”이라고 부르기 쉽습니다. 그러나 시험에서는 누구인지 확인하는가, 어떤 자원 접근을 위임하는가, 여러 서비스가 어떤 신원 정보를 신뢰하는가를 분리해야 합니다.

인증은 신원 확인, 인가는 허용 범위 결정입니다

단계확인 질문대표 결과
식별누구라고 주장하는가사용자 ID·계정 식별자
인증그 주장이 사실인가인증 성공·보증수준·인증 세션
인가어떤 자원과 행위를 허용할 것인가권한·scope·정책 결정

사용자가 로그인에 성공했다고 모든 문서에 접근할 수 있는 것은 아닙니다. 인증된 신원과 요청 맥락을 바탕으로 접근통제 정책이 별도의 인가 결정을 내립니다. 접근통제 모델은 DAC·MAC·RBAC·ABAC 글에서 이어서 확인할 수 있습니다.

MFA는 화면 수가 아니라 서로 다른 요소를 결합해야 합니다

비밀번호와 보안질문은 둘 다 사용자가 아는 지식 요소입니다. 비밀번호를 두 번 입력하거나 서로 다른 지식 두 개를 쓰는 것을 다요소 인증이라고 부를 수는 없습니다. 인증기는 지식, 소유, 생체 등 서로 다른 요소와 검증 절차로 구분해야 합니다. NIST는 인증기 유형과 보증수준, 피싱 저항성 요구를 별도로 다룹니다. 근거 원문

요소 분류
  1. 지식비밀번호·PIN처럼 사용자가 알고 있는 것
  2. 소유보안키·등록 단말·OTP 생성기처럼 사용자가 가진 것
  3. 생체지문·얼굴처럼 사용자 신체 특성으로 검증하는 것
  4. 주의생체정보는 보통 단독 비밀값처럼 교체할 수 없으므로 인증기 활성화·다른 요소와의 결합 맥락을 확인한다.

TOTP와 WebAuthn은 모두 소유 요소가 될 수 있지만 공격면이 다릅니다

TOTP는 공유 비밀과 현재 시간 단계를 이용해 일회용 값을 생성합니다. 서버와 인증기가 공유 비밀을 안전하게 보관하고 시간 오차를 관리해야 합니다.근거 원문 사용자가 코드를 피싱 사이트에 직접 입력하면 공격자가 짧은 유효시간 안에 중계할 수 있다는 한계도 있습니다.

WebAuthn은 relying party에 범위가 묶인 공개키 자격증명을 사용해 서버가 challenge에 대한 서명을 검증합니다. W3C Level 3 문서는 현재 Candidate Recommendation 상태이므로 구현 지원 범위는 제품 문서를 별도로 확인해야 합니다. 근거 원문

SSO는 한 번 로그인하는 경험이고 연합인증은 신뢰 경계를 연결합니다

SSO는 한 번의 인증으로 여러 서비스에 반복 로그인하지 않는 사용자 경험을 가리킵니다. 하나의 조직 내부 세션으로도 구현할 수 있고, 서로 다른 보안 도메인 사이에서 Identity Provider의 인증 결과를 Service Provider가 신뢰하는 연합 구조로도 구현할 수 있습니다.

SAML 웹 브라우저 SSO에서는 Identity Provider가 인증 결과와 속성을 assertion으로 전달하고 Service Provider가 서명·대상·수신자·유효시간 등을 검증합니다. assertion을 받았다는 사실만으로 무조건 신뢰하지 않습니다.근거 원문

OAuth는 권한 위임이고 OpenID Connect는 그 위에 인증 계층을 추가합니다

OAuth 2.0은 사용자의 자격증명을 제3자 애플리케이션에 넘기지 않고, 제한된 리소스 접근 권한을 위임하는 프레임워크입니다. Access Token은 보호 자원 접근에 쓰이며 그 자체가 보편적인 사용자 신원 증명서라고 가정하면 안 됩니다. scope와 토큰 수신자·발급자·유효기간을 맥락에 맞게 검증해야 합니다.근거 원문

OpenID Connect는 OAuth 2.0 위에 인증과 사용자 정보를 위한 identity layer를 정의하며 ID Token을 사용합니다. ‘소셜 로그인’ 화면이라고 해서 OAuth Access Token만으로 로그인 처리를 끝내면 안 됩니다.근거 원문

WORKED EXAMPLE

‘Google로 로그인’에서 OAuth와 OIDC를 구분하기

문제

한 앱이 사용자의 클라우드 사진 일부를 읽고, 동시에 사용자가 누구인지 로그인 처리하려 한다. OAuth 2.0만 사용했다고 답하면 충분한가?

약한 답

OAuth가 소셜 로그인이므로 충분하다.

개선한 답

사진 접근 권한 위임에는 OAuth 2.0을 사용한다. 사용자 인증에는 OpenID Connect의 인증 요청과 ID Token 검증을 사용한다. Access Token을 사용자 신원 증명으로 일반화하지 않는다.

  1. 01자원 찾기

    사진 API처럼 보호 자원에 대한 권한 위임 요구를 OAuth 범위로 분리합니다.

  2. 02신원 찾기

    로그인 처리에 필요한 발급자·대상·nonce·서명·시간 검증을 OIDC 흐름에서 확인합니다.

  3. 03토큰 역할 쓰기

    Access Token과 ID Token의 수신자와 사용 목적을 답안에 구분해 적습니다.

판별 포인트화면 이름이 아니라 토큰이 누구에게 발급됐고 어떤 결정을 위해 쓰이는지가 답을 가릅니다.

인증 문제는 공격자가 무엇을 훔쳐 재사용할 수 있는지 봅니다

인증과 인가를 분리했는가두 단계가 서로 다른 인증요소인가OTP 공유 비밀과 시간 오차를 고려했는가토큰의 발급자·대상·수신자를 검증하는가Access Token을 신원 증명으로 일반화하지 않았는가SSO assertion의 서명·시간·대상을 확인했는가

인증서와 공개키 신뢰 경로는 PKI·인증서·전자서명 글에서, 권한 결정은 접근통제 모델 글에서 함께 정리하세요.