AuthN과 AuthZ

AuthN(Authentication)

비밀번호 기반 인증

• 사용자의 신원을 확인하기 위해 비밀번호가 필요
• 사용자는 먼저 이메일 주소 및 비밀번호와 같은 필요한 세부 사항을 제공하여 계정을 작성한 뒤 액세스

비밀번호없는 인증

• 사용자는 매직 링크 또는 이메일 또는 문자 메시지를 통해 전달 된 OTP를 통해 로그인

2FA(Two Factor Authentication) / MFA(Multi Factor Authentication)

• 2 단계 또는 다중 요소 인증을 사용하여 추가 보안 계층을 강화 및 유연한 인증

Single Sign On

• SSO를 통해 사용자는 단일 자격 증명 세트로 여러 응용 프로그램에 액세스 할 수 있음
• 한 번의 시스템 인증을 통해 다양한 정보시스템에 재인증없이 접근할 수 있도록 개발된 방식

Social Authentication

• 소셜 네트워킹 플랫폼의 기존 자격 증명으로 확인하고 인증
• 이 방법은 Facebook, Twitter, Google 등과 같은 소셜 네트워킹 플랫폼의 기존 자격 증명을 사용하여 사용자를 식별함

API Authentication

• API 인증은 서버에서 서비스에 액세스하려는 사용자 식별을 인증하는 프로세스
• API Key / Token

생체인증

• 신원을 확인하기 위해 개인의 독특한 생물학적 특징의 사용을 포함
• 사용자의 생체 데이터가 캡처되어 데이터베이스에 저장된 후 사용자 인증을 확인하기 위해 비교
• 홍채, 지문, 얼굴, 행동 인식등이 있음

AuthZ(Authorization)

API keys

• 이 방법은 인증 및 권한 부여에도 사용됨
• 사용자가 등록 중에 시스템에 대한 인증 된 액세스 권한을 얻으려고하면 API key를 생성 받아 사용함
• API Key는 일반적으로 요청의 URL 또는 헤더에 포함하는 긴 문자열
• API 키는 주로 API를 호출하는 사람을 식별하는 수단으로 사용
• 이 방법은 AuthN 및 Authz 모두에서 사용
• 시스템-시스템 및 사용자-시스템 권한 관리를 위해 RBAC ( 역할 기반 액세스 제어 )를 구현할 수 있음

HMAC (Hash-Based Message Authentication Code)

• 암호화에서 HMAC은 암호화 해시 기능과 비밀 암호화 키를 포함하는 특정 유형의 메시지 인증 코드
• 다른 MAC(Message Authentication Code)과 마찬가지로 데이터 무결성과 메시지의 신뢰성을 동시에 확인하는 데 사용될 수 있음

JWT / JSON Web Token

• JWT는 당사자간에 안전하게 데이터를 전송하기위한 공개 표준이며 사용자는 공개 / 개인 키 쌍을 사용하여 권한을 부여받음

SAML / Security Assurance Markup Language

• 디지털 서명 된 XML 문서를 통해 인증 정보를 교환하는 표준 싱글 사인온 형식 (SSO)
• 서비스 공급자와 아이덴티티 공급자라는 두 엔터티 간의 XML 기반 인증 및 권한 부여 시스템

OpenID

• 인증 서버의 인증을 기반으로 사용자 신원을 확인하게 Authentication에 더 가까움
• 이를 통해 클라이언트는 Authorization Server의 인증을 기반으로 최종 사용자 ID를 확인할 수 있을뿐만 아니라
• 최종 사용자에 대한 상호 운용 가능하고 REST와 유사한 기본 프로파일 정보를 얻을 수 있음

OAuth

• 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용 접근 위임을 위한 개방형 표준
• 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용

AuthN VS AuthZ

ETC

HTTP 인증 스키마

서버에서는 클라이언트에서 선택할 여러 인증 체계를 지정할 수 있습니다. 다음 표에서는 Windows 애플리케이션에서 일반적으로 볼 수 있는 몇 가지 인증 스키마에 대해 설명합니다.

GPT

1. (HTTPS Header) HTTP Basic Authentication

• 설명: 가장 단순한 형태의 인증 방식으로, 사용자 ID와 비밀번호를 Base64로 인코딩하여 HTTP 헤더에 포함시켜 전송합니다.
• 장점: 간단하고 구현이 용이.
• 단점: 보안에 취약하며, SSL/TLS를 사용하여 암호화하지 않으면 쉽게 탈취될 수 있습니다.

GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

2. (HTTPS Header) HTTP Digest Authentication

• 설명: 사용자 인증 정보를 해싱하여 전송하는 방식으로, Basic Authentication보다 보안이 강화된 형태입니다.
• 장점: 인증 정보가 해시로 전송되므로 보안이 더 강력함.
• 단점: 구현이 비교적 복잡하며, 중간자 공격에 여전히 취약할 수 있습니다.

# 1단계: 서버가 클라이언트에게 challenge를 보냅니다.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="example.com",
                  qop="auth",
                  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                  opaque="5ccc069c403ebaf9f0171e9517f40e41"

# 2단계: 클라이언트가 응답을 보냅니다.
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Digest username="username",
                      realm="example.com",
                      nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                      uri="/protected-resource",
                      qop=auth,
                      nc=00000001,
                      cnonce="0a4f113b",
                      response="6629fae49393a05397450978507c4ef1",
                      opaque="5ccc069c403ebaf9f0171e9517f40e41"

3. (HTTPS Header) Token-based Authentication

• 설명: 사용자 인증 후, 서버가 클라이언트에게 토큰을 발급하고, 이후 요청에 이 토큰을 포함하여 인증합니다.
• JWT (JSON Web Token): 자가 포함된 토큰으로, 클라이언트와 서버 간의 신뢰성을 유지합니다.
• OAuth2: 주로 API 접근을 위해 사용되며, 액세스 토큰을 통해 리소스를 보호합니다.
• 장점: 세션 상태를 서버에 저장할 필요 없이 확장 가능.
• 단점: 토큰 유효기간 관리 및 토큰 탈취에 대한 보안 고려 필요.

GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

4. OAuth2

• 설명: 액세스 권한을 부여하는 인증 프로토콜로, 자원 소유자(Resource Owner)가 제3자 애플리케이션에게 자원 서버(Resource Server)에 접근할 수 있는 권한을 부여합니다.
• 장점: 권한 위임이 가능하고, 다양한 인증 흐름(Authorization Code, Implicit, Client Credentials, Password)을 지원.
• 단점: 비교적 복잡한 구현 및 설정.

5. OpenID Connect

• 설명: OAuth2를 기반으로 한 인증 프로토콜로, 사용자 인증을 위한 ID 토큰을 제공합니다.
• 장점: 표준화된 방식으로, 다양한 애플리케이션 간 통합이 용이.
• 단점: OAuth2의 복잡성을 내포.

6. SAML (Security Assertion Markup Language)

• 설명: XML 기반의 인증 및 권한 부여 표준으로, 주로 기업 환경에서 SSO(Single Sign-On)를 구현할 때 사용됩니다.
• 장점: 다양한 시스템 간의 SSO 구현에 유리.
• 단점: XML 기반으로 구현이 다소 복잡하고, 성능 오버헤드가 있을 수 있음.

7. X.509 Certificates

• 설명: 공개 키 기반의 인증 방식으로, 클라이언트와 서버가 서로를 인증하기 위해 X.509 인증서를 사용합니다.
• 장점: 높은 보안 수준, 상호 인증 가능.
• 단점: 인증서 관리가 복잡하고, 설정이 어려울 수 있음.

8. API Keys

• 설명: 클라이언트가 서버에 접근할 때 사용하는 고유의 키를 발급받아 인증합니다.
• 장점: 구현이 간단하고, API 접근 제어가 용이.
• 단점: 키가 유출될 경우 보안에 취약.

9. LDAP (Lightweight Directory Access Protocol)

• 설명: 디렉토리 서비스를 통해 사용자 정보를 관리하고, 인증을 수행합니다.
• 장점: 중앙 집중식 사용자 관리, 다양한 애플리케이션 통합 가능.
• 단점: LDAP 서버 설정 및 관리가 필요.

10. Kerberos

• 설명: 네트워크 인증 프로토콜로, 티켓(ticket)을 사용하여 사용자와 서비스를 상호 인증합니다.
• 장점: 높은 보안성, 티켓 기반 인증.
• 단점: 초기 설정이 복잡하고, 시간 동기화가 필요.

11. Mutual TLS (mTLS)

• 설명: 서버와 클라이언트가 서로를 인증하는 TLS 확장 방식입니다. 클라이언트와 서버 모두 X.509 인증서를 사용하여 상호 인증합니다.
• 장점: 매우 높은 보안 수준, 상호 인증 제공.
• 단점: 인증서 관리가 복잡하고, 설정이 어려울 수 있음.

각 인증 방식은 특정 사용 사례와 보안 요구사항에 맞추어 선택되어야 합니다. 예를 들어, 높은 보안이 요구되는 환경에서는 X.509 인증서나 mTLS를 사용할 수 있으며, 간단한 인증이 필요한 경우에는 API 키나 Basic Authentication을 사용할 수 있습니다. OpenID Connect와 OAuth2는 확장성과 보안성 모두를 제공하므로, 다양한 애플리케이션 통합에 적합합니다.