인증 프로토콜, 인증 관련

OAuth (Open Authorization) - 🔥 가장 중요!

 

이 사용자가 다른 앱에게 본인 정보 접근 권한을 줬는지 확인해줘

 

비밀번호 제공하지 않고!

접근 토큰(액세스 토큰), 권한 범위 지정!

인가!

 

✅ 개념

• SNS(구글, 네이버, 카카오) 로그인 연동에 사용되는 인증 프로토콜
• 3자 인증 방식(Third-party authentication)으로, 사용자의 ID/PW를 직접 제공하지 않고 인증 가능

 

인터넷 애플리케이션에서 사용자 인증에 사용되는 표준 인증 방법

공개 API(OpenAPI)로 구현되었다

인터넷 사용자가 웹사이트나 애플리케이션에 비밀번호를 제공하지 않고 자신에게 접근 권한을 부여하여 사용할 수 있다

2010년 ETF에서 1.0이 공식 표준안으로 발표되었다.

 

💡 예제

📌 사용자가 웹사이트에서 **"구글 계정으로 로그인"**을 선택하면, OAuth를 통해 구글이 사용자 인증을 처리하고, 해당 웹사이트는 구글로부터 접근 토큰을 받아 사용자 정보를 가져옴.

🛡 특징

✅ ID/PW를 직접 제공하지 않음 → 보안 강화
✅ 액세스 토큰을 사용하여 권한 범위 지정 가능 (예: 이메일만 제공)
✅ OAuth 2.0이 가장 널리 사용됨 (Facebook, Google, GitHub 로그인 지원)

 

 

OIDC (OpenID Connect) - OAuth + 사용자 인증

 

인증 직접 처리!

ID 토큰(JWT)

 

✅ 개념

• OAuth 2.0 기반에 사용자 인증(ID 토큰)을 추가한 프로토콜
• OAuth는 권한 위임만 가능하지만, OIDC는 사용자 정보(ID)도 제공 가능
• OAuth 는 인가, 어떤 권한이 있는지는 말해주지만 인증, 누구의 권한인지는 말하지 못한다

 

💡 예제

📌 OAuth는 웹사이트가 "사용자의 이메일 접근 권한만 부여"할 수 있지만,
📌 OIDC는 "이 사용자가 실제 누구인지"도 확인 가능!

 

🛡 특징

✅ OAuth 2.0의 확장 버전으로, 로그인 시스템 구현 가능
✅ JWT(JSON Web Token) 기반으로 토큰을 주고받음
✅ Google, Microsoft, Amazon 로그인 시스템에 OIDC 사용

 

 

OpenID (오픈ID) - 싱글 사인온(SSO, Single Sign On) 방식 인증

 

 

✅ 개념

• 하나의 ID로 여러 웹사이트에서 로그인할 수 있는 인증 프로토콜
• OAuth와 다르게 사용자 인증을 직접 처리함
• 현재는 OIDC(OpenID Connect)로 발전하여 OAuth 2.0과 결합됨

💡 예제

📌 Google 계정 하나로 여러 사이트에 로그인 가능

🛡 특징

✅ 하나의 계정으로 여러 사이트에서 로그인 가능 (SSO)
✅ 현재는 OIDC(OpenID Connect)로 대체됨

 

 

🔹 OIDC 인증(Authentication) 과정

 

OIDC는 OAuth 2.0의 인증 흐름(Authorization Code Flow)을 확장하여 사용.

즉, 사용자가 로그인하면 **ID 토큰(JWT)**이 발급되고, 이를 검증하여 사용자의 신원을 확인하는 방식.

 

1️⃣ 사용자가 로그인 요청

• 사용자가 클라이언트 애플리케이션(예: 웹사이트, 모바일 앱)에서 “Google로 로그인” 버튼을 클릭.

• 클라이언트는 **OIDC 프로바이더(IdP, Identity Provider)**에게 사용자의 인증을 요청함.

• 예: Google, Apple, Facebook, Microsoft 등

 

2️⃣ OIDC 프로바이더가 사용자 인증 수행

• OIDC 프로바이더(IdP)가 사용자에게 로그인 화면을 제공(예: Google 로그인 창).

• 사용자가 ID/PW 입력 또는 소셜 로그인, 생체인증(FIDO) 등을 통해 인증 수행.

• 인증이 완료되면, OIDC 프로바이더는 Authorization Code를 클라이언트에게 전달.

 

3️⃣ 클라이언트가 토큰 요청 (Authorization Code → 토큰)

• 클라이언트는 받은 Authorization Code를 사용하여 OIDC 프로바이더에게 토큰을 요청.

• OIDC 프로바이더는 Access Token + ID Token을 발급.

 

4️⃣ ID 토큰 검증 (사용자 신원 확인)

• 클라이언트는 ID 토큰(JWT)을 검증하여 사용자의 신원을 확인.

• ID 토큰에는 사용자의 이메일, 이름, 프로필 사진 등의 정보가 포함됨.

• ID 토큰은 JWT(JSON Web Token) 형식으로 서명되어 있으며, 검증을 통해 위조 여부를 확인 가능.

=> 서명되었다는건 토큰이 중간에 조작되지 않았다는 걸 확인할 수 있는 암호화된 증명값이 포함됐다는 뜻

 

5️⃣ 로그인 완료 & 세션 유지

• 검증이 완료되면 사용자는 로그인 상태가 유지됨.

• 이후 클라이언트는 사용자의 정보를 저장하고 세션을 관리하여 로그인을 유지할 수 있음.

 

⸻

 

🔹 OIDC에서 ID 토큰의 역할

 

OIDC에서 **ID 토큰(ID Token)**은 사용자의 신원을 확인하는 핵심 요소.

ID 토큰은 JWT(JSON Web Token) 형식으로 되어 있으며, 보안이 강화된 토큰이야.

 

✅ ID 토큰의 주요 정보 (Payload 부분)

 

{

  "iss": "https://accounts.google.com",  // 발급자(Identity Provider)

  "sub": "1234567890",                  // 사용자 고유 ID

  "aud": "my-client-id",                 // 클라이언트 ID

  "exp": 1712000000,                     // 만료 시간 (Unix Timestamp)

  "iat": 1711900000,                     // 발급 시간

  "email": "user@example.com",           // 사용자 이메일

  "name": "홍길동",                       // 사용자 이름

  "picture": "https://example.com/photo.jpg"  // 프로필 사진 URL

}

 

✅ ID 토큰 검증 방법

1. JWT 서명(Signature) 검증

• ID 토큰은 OIDC 프로바이더가 서명한 JWT이므로, 클라이언트는 공개키(Public Key)로 서명을 검증함.

• 이 과정을 통해 토큰이 위변조되지 않았음을 확인 가능.

2. 토큰 만료 시간(exp) 체크

• ID 토큰이 만료되었는지 확인하여, 만료된 토큰이면 재인증 요청.

3. 클라이언트 ID(aud) 확인

• ID 토큰이 올바른 클라이언트(애플리케이션)에서 사용되고 있는지 검증.

 

⸻

 

🚀 OIDC 로그인 처리 흐름 요약

1. 사용자가 “Google로 로그인” 버튼 클릭

2. OIDC 프로바이더(IdP)가 사용자 인증 수행 (ID/PW, 소셜 로그인 등)

3. Authorization Code 발급 → 클라이언트가 OIDC 프로바이더에게 토큰 요청

4. ID 토큰(JWT) + 액세스 토큰 발급

5. ID 토큰 검증 → 사용자 신원 확인 후 로그인 처리

6. 세션 유지 및 로그인 상태 관리

 

⸻

 

✅ OIDC vs 기존 로그인 방식의 차이

 

구분 기존 로그인 (ID/PW) OIDC 로그인

로그인 방식 ID/PW 입력 ID 토큰 검증

보안성 비밀번호 유출 위험 JWT 서명 검증으로 안전

SSO 지원 ❌ ✅ (SSO 가능)

모바일 친화성 ❌ ✅ (OAuth 2.0 기반)

API 인증 ❌ ✅ (액세스 토큰 활용 가능)

 

 

 

⸻

 

✅ 결론: OIDC를 사용하면?

• 소셜 로그인(Google, Facebook, Apple) 및 SSO 구현 가능

• ID 토큰을 통해 사용자의 신원을 안전하게 검증

• OAuth 2.0 기반이므로 API 인증과 연계 가능

• JWT 기반으로 빠르고 모바일/웹 친화적

 

📌 정보처리기사 실기 관련

✅ OIDC의 로그인 처리 과정과 ID 토큰 검증 방식이 시험에 나올 가능성이 있음!

• ID 토큰이 JWT 형식이며, 서명 검증이 필요하다는 점 기억!

• OIDC는 OAuth 2.0 기반이라는 점도 중요!

 

✅ 결론: OIDC는 SSO를 구현하는 하나의 방법!

• SSO는 “한 번 로그인하면 여러 애플리케이션에 자동 로그인”하는 개념

• OIDC는 OAuth 2.0을 확장한 인증 프로토콜 → SSO를 구현할 수 있는 표준 중 하나

• 기업 환경에서는 SAML 기반 SSO가 많이 사용됨, 반면 웹·모바일 앱에서는 OIDC가 많이 사용됨

 

📌 정보처리기사 실기 관련

✅ SSO의 개념과 OIDC, SAML의 차이점을 묻는 문제가 나올 가능성이 있음!

• SSO는 인증 방식의 개념, OIDC는 프로토콜

• OIDC는 OAuth 2.0 기반, SAML은 XML 기반

• API 인증, 모바일 친화성에서는 OIDC가 유리!

 

SSO (Single Sign On)

 

한 번의 로그인으로 개인이 가입한 모든 사이트를 이용할 수 있게 해주는 시스템

 

 

JAAS (Java Authentication and Authorization Service) - 자바 인증 프레임워크

✅ 개념

• Java 기반 애플리케이션의 인증(Authentication) 및 권한 관리(Authorization) 프레임워크
• Java 프로그램에서 사용자 로그인, 권한 부여 등을 처리할 때 사용

💡 예제

📌 자바 웹 애플리케이션에서 사용자 로그인 및 접근 제어 구현

🛡 특징

✅ 플러그인 방식(Pluggable) → 다양한 인증 방식 지원 가능
✅ J2EE(Java Enterprise Edition) 기반 보안 시스템에 사용됨

 

 

SSPI (Security Support Provider Interface) - 윈도우 인증 API

✅ 개념

• Windows에서 사용하는 인증 및 보안 통신 인터페이스
• Kerberos, NTLM 같은 윈도우 기반 보안 프로토콜을 지원

💡 예제

📌 Active Directory(AD) 환경에서 윈도우 서버 인증 처리

🛡 특징

✅ Windows 환경에서 Kerberos, NTLM 인증 지원
✅ Windows 네트워크 서비스, 원격 데스크톱(RDP)에서 사용

 

 

🔹 SASL(Simple Authentication and Security Layer)

 

 

애플리케이션 프로토콜에 인증 기능을 추가하기 위한 프레임워크

자체적으로 인증을 처리하지 못하는 프로토콜(SMTP, IMAP)에 플러그인 방식으로 인증 모듈을 붙여줌 (메일 전송 프로토콜 등에 인증 기능을 부여하는 구조)

다양한 인증 방식 지원

 

메일, LDAP, 데이터베이스 등에서 인증을 처리하는 표준 프레임워크

암호화되지 않은 기본 인증 방식(Plain), CRAM-MD5, DIGEST-MD5, GSSAPI 등을 지원

 

SASL은 네트워크 프로토콜과 관련된 인증 프레임워크라는 점 기억!

 

 

✅ SASL 동작 방식

1. 클라이언트가 SMTP, IMAP, LDAP 등의 서버에 연결

2. 서버가 SASL을 이용해 지원하는 인증 방식 목록을 제공

3. 클라이언트가 PLAIN, CRAM-MD5, SCRAM-SHA-1 등의 인증 방식을 선택하여 로그인

4. 서버가 인증을 확인하고, 성공하면 서비스 이용 가능

 

💡 SASL을 사용하는 프로토콜 예시:

• SMTP (메일 전송) → 이메일 발송 시 SASL 인증 사용

• IMAP/POP3 (메일 수신) → 메일 클라이언트 로그인

• LDAP (디렉토리 서비스) → 기업 내부 사용자 인증

 

🛡 특징

✅ 애플리케이션 프로토콜과 독립적으로 인증 처리 가능
✅ 메일 서버(SMTP, IMAP), 데이터베이스(MySQL)에서 사용됨

SASL은 특정 인증 방식이 아니라 인증을 처리하는 프레임워크

네트워크 프로토콜(SMTP, LDAP 등)에 인증 기능을 추가할 때 사용됨

 

 

✅ SASL vs OIDC vs SSO 차이점

 

SASL, OIDC, SSO는 모두 사용자 인증(Authentication)과 관련된 개념이지만, 목적과 동작 방식이 다름!

 

항목	SASL (Simple Authentication and Security Layer)	OIDC (OpenID Connect)	SSO (Single Sign-On)
정의	인증 프레임워크 (주로 응용 계층에서 사용), 네트워크 프로토콜에서 인증을 추가하는 프레임워크	OAuth 2.0 기반의 인증 프로토콜, 웹·모바일 애플리케이션에서 인증을 위한 표준 프로토콜	한 번 로그인하면 여러 서비스에 자동 로그인하는 개념 (OIDC, SAML 등이 SSO를 구현하는 데 사용됨)
주요 목적	클라이언트-서버 간 인증 방식 제공	사용자 인증 및 ID 토큰 제공	사용자 편의성과 보안 향상을 위한 인증 통합 방식
기술 형태	프로토콜 수준의 인증 인터페이스	인증 프로토콜 (OAuth 2.0 확장)	인증 개념 또는 솔루션 아키텍처
사용 예시	SMTP, IMAP, LDAP 등에서 사용자 인증 시 사용	웹/모바일 앱에서 로그인 (ex. 구글 계정 로그인)	구글 Workspace, MS Azure AD 등 통합 로그인 시스템
인증 주체	클라이언트 ↔ 서버 직접	사용자 ↔ OIDC 프로바이더 ↔ 앱	사용자 ↔ SSO 시스템 ↔ 여러 앱/서비스
토큰 사용 여부	사용하지 않음	ID Token, Access Token 사용	상황에 따라 OIDC/OAuth/SAML 등과 결합 가능
표준화 여부	IETF 표준 (RFC 4422)	IETF/OIDC 재단 표준	다양한 구현 존재 (SAML, OIDC 등과 결합)

 

 

🚀 결론: SASL, OIDC, SSO 언제 사용?

 

사용 사례 추천 기술

이메일 서버 로그인(SMTP, IMAP, POP3) SASL (PLAIN, CRAM-MD5, SCRAM)

API 인증, 소셜 로그인(Google, Facebook) OIDC (OAuth 2.0 기반)

기업 내부 SSO(사내 시스템 통합 로그인) SAML, OIDC, Kerberos

 

 

• SAML(Security Assertion Markup Language)

 

 

웹 기반 SSO를 위한 XML 기반 인증 프로토콜

웹 환경에서 사용자 인증 정보를 안전하게 전달

웹 기반 사용자 인증과 권한 부여 데이터를 교환하기 위한 표준

인증 정보를 XML 형식의 토큰(Assertion)으로 전달

주로 기업 간 SSO 연동에서 사용

 

회사 내부 시스템, 사내 포털에서 쓰는 전통적인 인증 시스템

 

🧩 구성 요소

구성 요소	설명
사용자 (User)	로그인하려는 주체 (예: 직원, 사용자 등)
IdP (Identity Provider)	인증을 담당하는 서버 (예: 회사 계정 서버, 구글 계정)
SP (Service Provider)	사용자가 접근하려는 서비스 (예: 구글 드라이브, 슬랙)

 

🧭 작동 방식 (간단 요약)

1. 사용자가 SP(서비스)에 접근
2. SP는 IdP로 리디렉션 → 인증 요청
3. 사용자는 IdP에서 로그인
4. IdP는 SAML 어서션(assertion) 생성해서 SP에 전달
5. SP는 SAML 어서션을 검증하고 사용자 로그인 처리

 

 

🔍 예시

• 사용자가 회사 계정으로 슬랙, 드롭박스 등에 자동 로그인할 때
• Google Workspace, Microsoft Azure AD 등과 연동된 앱에서 사용

 

 

PEAP (Protected Extensible Authentication Protocol) - Wi-Fi 인증

 

✅ 개념

• 무선 네트워크(Wi-Fi)에서 보안 강화를 위해 사용하는 인증 프로토콜
• EAP(Extensible Authentication Protocol) 기반으로 TLS 암호화 적용

💡 예제

📌 기업 내 보안 Wi-Fi(802.1X) 환경에서 사용자 인증 시 사용

🛡 특징

✅ EAP보다 강력한 보안 제공 (TLS 암호화 적용)
✅ Wi-Fi 기업 네트워크에서 널리 사용됨