안전한 애플리케이션 연동을 위한 앱 등록 및 OAuth 가이드

By Mirko Peters · 2026-05-04

OAuth 2.0으로 앱을 등록하세요. 보안 액세스를 위한 권한 부여 코드 흐름을 이해하세요. OAuth 2.0 권한 부여 코드 부여(authorization code grant)의 핵심 부분입니다.

Automatically translated with AI from the original post. Read the English original

솔직히 말해서, 인증과 앱 등록을 제대로 하는 일은 영리한 프로토콜을 따르는 것에 그치지 않습니다. 사용자, 데이터, 그리고 조직이 안전하게 유지되도록 하는 일입니다. 이 가이드는 앱 등록과 OAuth 2.0을 쉽게 풀어 설명하여, Microsoft Entra ID(이전 명칭 Azure AD) 또는 원하는 공급자를 사용해 보안이 강화된 표준 기반 인증을 구축할 수 있도록 돕습니다.

OAuth를 이해해야 하는 이유부터 웹, 모바일, SaaS 앱에서 실제로 구현하는 방법까지, 필요한 단계와 개념을 차례로 살펴봅니다. 그 과정에서 명확한 정의, 실용적인 조언, 그리고 연동이 올바른 방향으로 진행되도록 하고 OAuth를 처음 다루는 개발자들이 흔히 저지르는 실수를 피하도록 돕는 로드맵을 확인할 수 있습니다. OAuth를 처음 살펴보는 분이든 고급 엔터프라이즈 환경을 세밀하게 조정하는 분이든, 자신 있게 구축하고 애플리케이션에 필요한 식별자를 이해하기에 적합한 자료입니다.

앱 등록 및 OAuth 가이드 — 정의

앱 등록은 애플리케이션이 인증과 권한 부여를 안전하게 요청할 수 있도록, ID 공급자(Azure AD, Google, Auth0 등)에 애플리케이션 ID를 만들고 구성하는 과정입니다. 일반적으로 클라이언트 ID, 클라이언트 암호 또는 인증서를 할당하고, 리디렉션 URI를 정의하며, 권한 및 범위(scope)를 설정하고, 허용할 권한 부여 유형(grant type)을 구성하는 작업을 포함합니다.

앱 등록 및 OAuth 가이드에 관한 놀라운 사실 8가지

• 클라이언트 암호가 로그를 통해 유출될 수 있습니다: 많은 개발자가 디버깅 중에 자신도 모르게 클라이언트 ID와 암호를 로그에 기록합니다. 로깅 정책을 강화하지 않으면 앱 등록 자격 증명이 노출될 수 있으므로, 식별자는 항상 신중하게 다루어야 합니다.
• 리디렉션 URI는 예상보다 엄격합니다: OAuth 공급자는 후행 슬래시와 스킴(scheme)을 포함해 정확히 일치하는 리디렉션 URI를 요구하는 경우가 많습니다. 따라서 사소한 차이만 있어도 앱 등록에서 올바르게 구성된 것처럼 보이는 흐름이 실패할 수 있습니다.
• 퍼블릭 클라이언트는 암호가 필요 없지만 여전히 보호가 필요합니다: 네이티브 앱과 단일 페이지 앱은 클라이언트 암호 없이 퍼블릭 클라이언트로 취급되지만, 권한 부여 코드 가로채기를 막기 위해 PKCE와 안전한 리디렉션 방식을 반드시 사용해야 합니다.
• 범위가 기본값으로 최소 권한을 보장하지는 않습니다: 앱을 등록할 때 기본 범위나 동의 화면이 광범위한 권한을 요청할 수 있습니다. 최소 권한 원칙을 적용하려면 범위를 명시적으로 제한하고 점진적 동의를 사용하는 것이 필수입니다.
• 토큰 취소가 모든 환경에서 지원되는 것은 아닙니다: 모든 ID 공급자가 토큰 취소를 지원하거나 여러 세션에 걸쳐 즉시 로그아웃을 제공하지는 않습니다. 따라서 앱 등록에는 세션 관리와 새로 고침 토큰 정책이 반드시 포함되어야 합니다.
• 앱 등록 메타데이터도 공격 표면입니다: 공개적으로 노출된 앱 이름, 로고, 리디렉션 URI는 신중하게 관리하지 않으면 공격자가 그럴듯한 피싱이나 열린 리디렉션 공격을 설계하는 데 악용될 수 있습니다.
• 자동 프로비저닝이 권한을 잘못 구성할 수 있습니다: 앱 등록을 생성하는 CI/CD 자동화는 과도하게 허용적인 API 권한을 부여하거나 필요한 리디렉션 URI를 등록하지 못하는 경우가 많습니다. 이는 조용한 실패나 보안 노출로 이어질 수 있습니다.
• 동의 UX가 보안 결정에 영향을 미칩니다: 동의 대화 상자가 혼란스럽기 때문에 사용자와 관리자가 광범위한 동의를 자주 부여합니다. 앱 등록과 OAuth 가이드에서 명확하고 최소한의 동의 안내를 설계하면 과도한 액세스 부여를 줄일 수 있습니다.

Microsoft Entra ID와 OAuth 2.0의 기본 이해

OAuth 2.0은 최신 인증 흐름의 핵심이며, 앱이 사용자의 암호를 전혀 보지 않고도 사용자 데이터와 리소스에 안전하게 접근할 수 있게 해 줍니다. OAuth 프로세스의 개요는 다음과 같습니다. 기본적으로 OAuth 2.0은 사용자(“리소스 소유자”), 앱(“클라이언트”), ID 공급자(“권한 부여 서버”)가 어떻게 함께 동작하는지를 정의하여 사용자가 자신의 정보를 계속 통제할 수 있도록 합니다.

그런데 데이터 접근 권한을 부여하는 것을 넘어 사용자를 인증해야 한다면 어떻게 할까요? 이때 사용되는 것이 OpenID Connect입니다. OpenID Connect는 OAuth 2.0 위에 안전한 ID와 로그인 기능을 추가합니다. OpenID Connect를 사용하면 Microsoft Entra ID나 Google 같은 공급자를 통해 앱이 사용자가 누구인지 확인하고, 하나의 통합된 환경에서 추가 리소스에 대한 범위가 지정된 권한을 요청할 수 있습니다.

“클라이언트 ID”, “권한 부여 엔드포인트”, “액세스 토큰” 같은 용어가 나오더라도 너무 부담 갖지 마십시오. 이 용어들은 모두 누가 누구와 통신하며 무엇을 할 수 있는지를 정의하는 것과 연결됩니다. 특히 Microsoft Entra ID는 이러한 프로토콜을 사용하여, 단일 테넌트 비즈니스 앱부터 대규모 멀티 테넌트 SaaS 제품에 이르기까지 개발자에게 표준 기반의 기반을 제공합니다.

이러한 기본 개념을 이해하면 검증된 토대 위에서 개발할 수 있습니다. 시나리오에 맞는 OAuth 흐름을 선택하는 것이 중요합니다. 예를 들어 웹 앱에는 코드 흐름, 스마트 TV에는 디바이스 흐름을 사용하면 안전하고 간단한 로그인 경험을 제공할 수 있으며, 사용자는 이를 신뢰하고 컴플라이언스 팀도 높이 평가할 것입니다.

앱 등록 및 OAuth 가이드: Microsoft Entra ID와 OAuth 2.0 사용 시 흔한 실수

이 앱 등록 및 OAuth 가이드에서는 팀이 Microsoft Entra ID(Azure AD)와 함께 OAuth 2.0을 구현할 때 자주 저지르는 실수와 그것이 보안, 기능 및 사용자 경험에 미치는 영향을 정리합니다.

• OAuth 2.0과 OpenID Connect 개념을 혼동하는 경우입니다(예: 액세스 토큰만 발급되는 상황에서 ID 토큰을 기대하는 경우).
• OAuth 흐름을 잘못 사용하는 경우입니다. 최신 앱에 암시적 흐름(implicit flow)이 적합하다고 판단하고, PKCE를 사용하는 권한 부여 코드 흐름 대신 이를 사용하는 경우가 여기에 해당합니다.

• 리디렉션 URI를 잘못 등록하는 경우입니다(잘못된 스킴, 끝에 붙은 슬래시, 운영 환경에서 localhost 사용 등).
• 기밀 앱에 퍼블릭 클라이언트 설정을 사용하거나 그 반대로 설정하여 토큰 오류가 발생하거나 비밀이 노출되는 경우입니다.
• 올바른 API 권한이나 범위(scope)를 설정하지 않거나, 필요한 곳에서 관리자 동의를 부여하는 것을 잊는 경우입니다.

• 클라이언트 측 코드나 공개 리포지토리에 클라이언트 비밀을 포함시키는 경우입니다.
• 비밀이나 인증서를 정기적으로 교체하지 않거나, 앱 등록에서 만료된 자격 증명을 제거하지 않는 경우입니다.
• 단기 인증서나 관리 ID 대신 불필요하게 수명이 긴 비밀을 사용하는 경우입니다.

• 토큰을 제대로 검증하지 않는 경우입니다(발급자, 대상(audience), 서명, nonce, 만료 시간(exp) 등).
• 액세스 토큰이나 새로 고침 토큰을 안전하지 않게 저장하는 경우입니다(보호되지 않은 브라우저 로컬 스토리지 사용 등).
• Entra ID가 반환한 범위(scope)나 역할(role)을 검증하지 않고 토큰 내용을 그대로 신뢰하는 경우입니다.

• 사용자 동의가 곧 앱 권한이라고 가정하는 경우입니다. 일부 권한은 관리자 동의가 필요하다는 점을 간과하는 것입니다.
• 과도한 권한이나 범위를 요청하는 경우입니다. 이는 불필요한 위험을 초래하고 동의 과정에서 거부율을 높입니다.

• Entra ID의 새로 고침 토큰 순환(rotation) 및 해지 정책을 처리하지 않아 예상치 못한 로그아웃이 발생하는 경우입니다.
• 적절한 보호 장치 없이 퍼블릭 클라이언트에서 새로 고침 토큰을 사용하는 경우입니다(PKCE와 적절한 토큰 수명을 사용하십시오).

• 여러 테넌트에서 동작하도록 의도된 앱의 멀티 테넌트 설정을 올바르게 구성하지 않는 경우입니다.
• 잘못된 엔드포인트(테넌트 전용 대 common)를 사용하여 로그인이나 동의 문제가 발생하는 경우입니다.

• 조건부 액세스, MFA 또는 디바이스 규정 준수 정책이 적용될 때 앱 동작을 테스트하지 않는 경우입니다.
• 토큰이 항상 동일한 조건에서 발급될 것이라고 가정하는 것입니다. 정책에 따라 토큰 발급이 차단되거나 추가 인증 단계가 요구될 수 있습니다.

• 최신 Microsoft ID 플랫폼(v2) 권장 사항 대신 기존 OAuth 흐름이나 Azure AD v1 방식을 따르는 것입니다.
• 보안 방식(PKCE, 안전한 저장소, 적절한 유효성 검사)을 구현하고 있는지 확인하지 않고 커뮤니티 샘플을 사용하는 것입니다.

• 인증 실패나 토큰 발급 오류를 기록하지 않으면 원인을 파악하기 어렵습니다.
• 사용자에게 원시 오류 메시지를 그대로 표시하면, 사용자가 조치할 수 있는 안내로 바뀌지 않습니다.

이 앱 등록 및 OAuth 가이드를 활용하여 구현을 검토하고, Microsoft ID 플랫폼 모범 사례를 따르며, Entra ID와 OAuth 2.0을 통합할 때의 보안 및 운영 위험을 줄이십시오.

OAuth 설정을 위한 앱 등록 사전 요구 사항

등록 화면으로 넘어가 앱 이름을 포털에 입력하기 전에, 반드시 확인해야 할 몇 가지 사항이 있습니다. 먼저 조직의 Microsoft Entra 관리 센터, 또는 사용 중인 ID 공급자의 해당 콘솔에 접근할 수 있어야 합니다. 적절한 권한이 없으면 시작 단계에서부터 막히게 됩니다.

다음으로, 어떤 종류의 애플리케이션을 만들 것인지와 기능에 필요한 식별자가 무엇인지 정해야 합니다. 웹 앱입니까, 단일 페이지 애플리케이션입니까, 모바일 앱입니까, 아니면 자동화된 서비스입니까? 각 유형은 인증과 권한 부여에 대해 고유한 요구 사항을 갖습니다. 이 단계에서 유형을 먼저 정해두면 이후에 선택할 보안 설정의 방향이 정해집니다.

또한 애플리케이션을 사용할 대상을 명확히 정리하는 것이 중요합니다. 조직 내부 사용자만 사용합니까(단일 테넌트)? 아니면 다른 기업이나 일반 공개 사용자에게도 서비스해야 합니까(다중 테넌트)? 이에 따라 등록 설정, 적용되는 사용자 디렉터리, 사용자에게 표시되는 동의 흐름이 달라집니다.

마지막으로 로그인 리디렉션에 허용할 URL, 지원할 플랫폼(iOS, Android, Windows 등), 앱이 요청해야 할 권한(또는 "범위")과 같은 기술적 세부 정보를 수집하십시오. 이러한 항목을 미리 맞춰 두면 설정 시간을 크게 줄이고, 잘못된 URI나 나중에 계정 유형이 맞지 않는 문제 같은 흔한 함정을 피할 수 있습니다.

Microsoft Entra ID에 앱 등록하기

Microsoft Entra ID(이전 명칭 Azure AD)에 앱을 등록하면 모든 인증 및 API 액세스 작업의 기반이 마련됩니다. 절차는 Entra 관리 센터에서 시작하며, 여기서 새 애플리케이션 등록을 만들고 조직 디렉터리 안에서 앱에 고유한 ID("클라이언트 ID"라고 함)를 부여합니다.

애플리케이션 이름을 입력한 다음, 누가 사용할 수 있는지 선택합니다. 자신의 조직만 사용할지, 여러 조직을 대상으로 할지, 아니면 모든 Microsoft 계정을 허용할지 결정합니다. 이 단계는 특히 SaaS 및 B2B 앱에서 매우 중요합니다. 앱의 사용 범위와 테넌트 동의 관리 방식을 결정하기 때문입니다.

대상을 선택한 후에는 앱의 플랫폼 세부 정보를 구성합니다. 웹 앱이라면 리디렉션 URI를 추가하고, 모바일 앱이나 단일 페이지 앱이라면 플랫폼별 설정으로 원활한 로그인 환경을 보장합니다. Entra 포털에서는 앱이 자신의 신원을 증명하는 데 사용할 클라이언트 암호나 인증서 같은 자격 증명을 추가하는 과정을 안내합니다.

등록을 마치면 앱이 OAuth 2.0 표준에 맞춰지고, 인증 흐름이 안전하고 규정을 준수하도록 유지됩니다. 단일 테넌트로 갈지 다중 테넌트를 목표로 할지와 관계없이, 이 설정을 일찍 이해해 두면 향후 확장과 통합 요구에 대비하는 탄탄한 기반이 됩니다.

Microsoft Entra ID에 앱 등록의 주요 이점

• 중앙 집중식 ID 관리: 단일 Entra ID 테넌트에서 앱의 인증, 권한 부여 및 사용자 ID를 관리합니다.
• 안전한 OAuth 흐름: 기본 제공되는 OAuth 2.0 및 OpenID Connect 지원을 활용하여 안전한 로그인, 토큰 발급 및 위임된 액세스를 구현합니다.
• 单一 로그인(SSO): Microsoft 365, Azure 및 기타 연동 서비스 전반에서 끊김 없는 SSO를 제공하여 사용자 경험을 개선하고 암호 입력 요청을 줄입니다.
• 세분화된 권한 제어: 위임된 권한과 애플리케이션 권한 모두에 대해 세분화된 API 권한을 정의하고 관리하며, 동의 환경과 최소 권한 액세스를 구성합니다.
• 조건부 액세스 및 보안 정책: 애플리케이션 액세스와 민감한 데이터를 보호하기 위해 MFA, 디바이스 규정 준수, 위치, 위험 기반 정책을 적용합니다.
• 관리되는 앱 비밀 및 자격 증명: 수명 주기 관리 방식을 적용하여 클라이언트 비밀, 인증서, 멀티 테넌트 구성을 안전하게 저장하고 교체함으로써 애플리케이션 사용의 무결성을 유지합니다.
• Microsoft 플랫폼 서비스와의 통합: 표준화된 토큰과 동의 모델을 사용하여 Microsoft Graph, Azure API, Teams 및 기타 플랫폼 기능에 액세스합니다.
• 하이브리드 및 멀티 플랫폼 앱 지원: 일관된 ID 프로토콜로 웹, 모바일, 데스크톱, 서비스 간(service-to-service) 시나리오에서 사용자를 인증하고, 각 애플리케이션이 올바른 식별자를 사용하도록 합니다.
• 모니터링 및 감사: 로그, 로그인 보고서, 보안 인사이트를 활용하여 이상 징후를 탐지하고, 인시던트를 조사하며, 규정 준수를 유지합니다.
• 확장성 및 엔터프라이즈 준비 상태: Entra ID의 글로벌 인프라, 멀티 테넌트 옵션, 엔터프라이즈 기능을 활용하여 늘어나는 사용자 기반과 복잡한 조직 요구 사항을 지원합니다.
• 개발자 도구 및 문서: SDK, 샘플 코드, 앱 등록 & OAuth 가이드를 활용하여 구현을 앞당기고 일반적인 문제를 해결합니다.

Entra ID 앱의 리디렉션 URI 및 플랫폼 설정 구성

앱 등록 시 올바른 리디렉션 URI를 설정하는 일은 간단해 보이지만, 보안에서는 성패를 가르는 단계입니다. 리디렉션 URI는 로그인이 성공한 후 토큰과 함께 사용자를 어디로 보낼지 Entra ID에 알려 줍니다. 이를 설정할 때 Entra ID는 엄격한 규칙을 적용합니다. 와일드카드 도메인, 위험한 URI 스킴, 공격자가 악용할 수 있는 느슨한 설정은 허용되지 않습니다.

싱글 페이지 애플리케이션(SPA)을 구축하는 경우에는 일반적으로 앱 도메인을 가리키는 HTTPS URL을 사용하여 애플리케이션이 데이터를 가져올 때 안전한 통신을 보장합니다. 네이티브 앱은 앱 번들 또는 패키지 이름에 연결된 URI 스킴을 사용해야 하며, 이를 통해 같은 기기의 임의의 앱이 토큰을 가로채는 것을 방지합니다. 웹 앱은 보통 로그인 콜백 엔드포인트를 사용하며, 각 엔드포인트를 명시적으로 등록해야 합니다.

이 부분을 잘못 구성하면 흔히 발생하는 “redirect URI mismatch” 오류가 나타나며, 더 심각하게는 공격자가 토큰을 가로챌 여지가 생깁니다. 앱이 실행될 각 플랫폼과 해당 리디렉션 URI를 미리 정리해 두면 인증이 원활하게 작동하고 안심할 수 있습니다.

클라이언트 URL을 변경하거나, 플랫폼을 추가하거나, 테스트 및 프로덕션과 같은 환경을 확장할 때마다 앱 등록 정보를 업데이트하십시오. URI를 잠그고 체계적으로 관리하는 것이 토큰 흐름을 안전하게 유지하는 첫 단계입니다.

OAuth 흐름 및 토큰 관리 핵심

OAuth 2.0은 웹 로그인, 모바일 로그인, 서버 간 호출, 사용자가 없는 상태에서 실행되는 앱 등 다양한 사용 사례를 처리하는 여러 권한 부여 흐름을 기반으로 합니다. 이 중 가장 널리 쓰이고 안전한 방식은 권한 부여 코드 흐름으로, 민감한 토큰을 브라우저와 모바일 앱 밖에 두도록 설계되어 보안을 최우선으로 합니다.

사용자가 인증되고 동의를 부여하면 앱은 수명이 짧은 코드를 받습니다. 앱은 이 코드를 토큰 엔드포인트에서 액세스 토큰 및 새로 고침 토큰과 교환해야 합니다. 이 토큰은 기간이 제한된 데이터 액세스 권한을 부여하며, 만료되면 새로 고침 토큰으로 새 액세스 토큰을 요청하여 세션을 유지할 수 있습니다.

토큰 관리는 만료 날짜를 처리하는 것에 그치지 않고, 모든 단계에서 토큰을 안전하게 유지하는 일입니다. 여기에는 HTTPS와 같은 보안 통신 사용, 클라이언트 측 코드에 비밀을 노출하지 않기, 범위를 요청할 때 최소 권한 원칙 적용이 포함됩니다.

이 섹션을 읽으면 OAuth가 사용자, 앱, 플랫폼 사이의 핵심 핸드셰이크를 어떻게 처리하는지, 그리고 견고한 토큰 관리가 최종 사용자와 자동화된 시스템 모두를 위한 지속적이고 안전한 워크플로를 어떻게 지원하는지 이해하게 됩니다.

OAuth 권한 부여 코드 흐름 구현

1. 권한 부여 시작: 앱은 사용자를 Entra ID 권한 부여 엔드포인트로 리디렉션하며, 이때 클라이언트 ID, 요청한 범위, CSRF 보호를 위한 고유하고 무작위인 state 매개변수 등의 정보를 포함합니다.
2. 사용자 권한 부여: 사용자는 앱에 필요한 권한이 명확하게 표시된 동의 화면을 검토한 후 액세스를 승인합니다.
3. 권한 부여 코드 받기: 동의가 완료되면 Entra ID는 지정한 리디렉션 URI로 다시 리디렉션하면서 임시 권한 부여 코드와 처음에 설정한 state 값을 함께 전달합니다.
4. 코드를 토큰으로 교환하기: 백엔드는 코드와 클라이언트 자격 증명(PKCE를 사용하는 경우 PKCE 코드 verifier 포함)을 Entra 토큰 엔드포인트로 안전하게 전송합니다. 검증이 완료되면 액세스 토큰과 (대부분의 경우) 새로 고침 토큰을 돌려받습니다.
5. 토큰으로 API 액세스하기: 앱은 이제 각 API 요청에 액세스 토큰을 포함하여 사용자를 대신해 권한이 있음을 증명합니다. 액세스 토큰은 노출 위험을 줄이기 위해 짧은 시간 동안만 유효하며, 새로 고침 토큰은 지속적인 세션을 위해 새 액세스 토큰을 발급받는 데 사용됩니다.

이 단계를 올바른 순서로 정확히 구현하면 보안 취약점을 막을 수 있으며, 특히 퍼블릭 클라이언트를 다monkey 하거나 민감한 데이터를 처리할 때 코드 가로채기나 토큰 오용과 같은 공격을 예방하는 데 도움이 됩니다.

액세스 토큰 및 새로 고침 토큰 만료 관리를 위한 모범 사례

1. 토큰을 안전하게 저장하기: iOS의 Keychain, Android의 Keystore, 또는 서버의 암호화된 비밀 관리자처럼 운영체제가 제공하는 안전한 저장소를 사용하십시오. 토큰을 앱 바이너리에 하드코딩하거나 로그에 노출하지 마십시오.
2. 토큰 수명 존중하기: 각 토큰의 만료 값(exp 클레임)을 모니터링하고, 토큰이 만료되기 전에 미리 새로 고침하여 API 요청 실패와 나쁜 사용자 경험을 방지하십시오.
3. 토큰 순환 지원하기: 각 요청에 항상 최신 새로 고침 토큰을 사용하고, 재사용되었거나 오래된 토큰은 신속히 폐기하십시오. 이렇게 하면 토큰이 유출되었을 때 피해 범위를 제한할 수 있습니다.
4. 토큰별 권한 최소화하기: 필요한 스코프만 요청하고 수명이 짧은 액세스 토큰을 사용하는 것이 좋습니다. 토큰이 유출되거나 도난당했을 때 피해를 크게 줄여 줍니다.

다양한 환경에서 OAuth 구현 보호하기

OAuth 통합을 올바르게 구현하려면 단순히 단계를 체크하는 것 이상이 필요합니다. 앱의 아키텍처와 사용 패턴에 맞춰 여러 계층의 보안을 설계해야 합니다. 앱이 브라우저에서 실행되든, 휴대폰에서 실행되든, 클라우드에서만 실행되든 각 환경에 맞는 인증 전략이 필요합니다.

PKCE(Proof Key for Code Exchange)와 같은 기술은 퍼블릭 클라이언트의 코드 흐름을 강화하여, 공격자가 코드를 가로채 토큰으로 바꾸는 것을 막아 줍니다. 반면 보안 환경에서 실행되는 앱에는 클라이언트 비밀과 인증서가 신원을 입증하고 신뢰를 관리하는 가장 좋은 도구가 됩니다.

토큰을 신중하게 저장하고 권한 수준을 면밀히 살피면 실수로 인한 유출을 방지하고, 문제가 발생했을 때 영향 범위를 제한할 수 있습니다. PKCE, 비밀, 인증서, 적절한 스코프 지정 등 올바른 보안 도구를 선택하면 공격 표면을 크게 줄이고 안정적이고 규정을 준수하는 운영 가능성을 높일 수 있습니다.

아래에서는 다양한 위협에 대응하고 모든 종류의 앱과 환경에 맞게 OAuth 설정을 견고하게 보호하기 위해 검증된 전략을 살펴봅니다.

퍼블릭 클라이언트에서 PKCE가 OAuth 권한 부여를 보호하는 방법

PKCE(Proof Key for Code Exchange)는 모바일 및 브라우저 기반 앱처럼 비밀을 안전하게 저장할 수 없는 퍼블릭 클라이언트에서 OAuth를 사용할 때 매우 중요합니다. 권한 부여 코드 흐름을 시작하면 앱은 무작위 "code verifier"와 해시된 "code challenge"를 생성합니다. 이 값들은 사용자 흐름과 마지막 토큰 요청에 함께 전달됩니다. 공격자가 권한 부여 코드를 가로채더라도 이 비밀 verifier 없이는 토큰으로 교환할 수 없으므로, Microsoft Entra ID 및 유사한 플랫폼에서 코드 가로채기 공격은 사실상 불가능해집니다.

클라이언트 비밀, 인증서 및 페더레이션 자격 증명 관리하기

• 클라이언트 비밀: 신뢰할 수 있는 백엔드 서비스와 같은 기밀 앱이 토큰 엔드포인트에서 자신의 신원을 증명할 때 사용합니다. 비밀은 보안 자격 증명 저장소에 보관하고, 정기적으로 교체하며, 클라이언트 측 앱 코드에 절대 포함하지 마십시오.
• 인증서: 더 높은 보증 수준이 필요하다면 일반 비밀 대신 X.509 인증서를 사용하여 애플리케이션 식별자의 보안을 강화하십시오. 인증서는 공개 키/개인 키 쌍을 통해 더 안전한 검증을 가능하게 하며, 규제가 엄격한 산업이나 엄격한 규정 준수가 요구되는 앱에 이상적입니다.
• 페더레이션 자격 증명: "자체 신원 가져오기(bring your own identity)" 구성에는 Microsoft Entra의 페더레이션 ID나 외부 공급자와 같은 페더레이션 자격 증명을 사용하십시오. 이를 통해 비밀을 직접 다루지 않고도 인증할 수 있어 관리 부담이 줄어듭니다.
• 파이프라인 처리: CI/CD 워크플로에서는 필요에 따라 비밀과 인증서를 주입하고 교체하되, 소스 제어에 하드코딩하지 마십시오. 자동 만료 알림은 복원력을 한 겹 더해 줍니다.

토큰 보호 및 권한 노출 최소화

• 토큰은 OS 자격 증명 저장소(vault)나 암호화된 서버 환경 같은 안전한 위치에만 저장하고, 사용자가 접근할 수 있는 저장소에는 절대 저장하지 마십시오.
• 토큰은 항상 HTTPS 또는 보안 채널로 전송하십시오. 일반 HTTP를 사용하면 토큰이 가로채기에 노출됩니다.
• 토큰마다 필요한 최소 권한("스코프")만 요청하십시오. 앱에 필요한 것 이상을 요청해서는 안 됩니다.
• 토큰 사용 현황과 권한 할당을 정기적으로 점검하여, 눈에 띄지 않게 권한이 점점 커지는 현상을 방지하십시오.

모바일 및 네이티브 애플리케이션에서의 OAuth 모범 사례

오늘날 모바일 및 네이티브 앱에는 고유한 어려움이 있습니다. 기기를 잃어버릴 수 있고, 앱끼리 저장 공간을 공유하며, 사용자는 빠르고 거의 보이지 않는 로그인을 기대합니다. 그래서 iOS, Android, 데스크톱에서 내장 SDK와 검증된 저장 메커니즘을 사용해 OAuth 모범 사례를 따르는 것이 큰 차이를 만듭니다.

Microsoft Entra ID용 MSAL 같은 적절한 SDK가 많은 복잡한 작업을 처리합니다. 토큰 관리, 갱신 로직 처리, OS 수준 보안 저장소와의 통합을 맡아 줍니다. 민감한 토큰의 경우, 이러한 SDK는 기본적으로 가장 안전한 저장 위치를 판단하고, 기기 또는 OS별 특이 사항도 함께 처리합니다.

원활한 UX도 놓치지 마십시오. 유니버설 링크, 딥 링크, 시스템 브라우저 흐름을 활용하면 사용자가 혼동이나 피싱 위험 없이 로그인을 마칠 수 있습니다. 올바르게 구성하면 앱은 사용자를 안전하고 신뢰할 수 있는 시스템 웹 뷰로 넘긴 뒤, 로그인이 끝나면 다시 앱 안으로 안전하게 돌려보냅니다. 팝업도, 토큰 유출도 없습니다.

이러한 사례는 토큰을 안전하게 보호할 뿐만 아니라 최종 사용자의 신뢰를 쌓도록 설계되었습니다. 이를 통해 도입률을 높이고 이후의 지원 부담도 줄일 수 있습니다.

유니버설 링크와 퍼스트 파티 네이티브 인증

유니버설 링크(iOS)와 앱 스킴(Android)은 사용자 인증을 훨씬 안전하게 만들어 줍니다. 앱의 ID에 연결된 OS 검증 링크를 사용하면, 악성 앱이 로그인 리디렉션을 가로채 다른 사람의 토큰을 탈취하는 일을 막을 수 있습니다. 네이티브 인증은 신뢰할 수 있는 시스템 브라우저를 활용하므로 실제 사용자가 로그인하게 되며, 피싱, 토큰 스누핑, 관련 없는 앱 간의 잘못된 로그인을 원천적으로 차단합니다. 이 도구들을 함께 사용하면 일반적인 모바일 OAuth 위협에 거의 완벽하게 대응하는 매끄럽고 안전한 경험을 사용자에게 제공할 수 있습니다.

OAuth 오류 문제 해결 및 고급 시나리오

OAuth 연동은 처음부터 완벽하게 동작하는 경우가 거의 없습니다. 오류와 예외 상황은 이 작업의 일부입니다. 종종 리디렉션 URI 불일치, 만료된 코드, 잘못된 클라이언트 비밀 값 때문에 문제가 생기며, 이로 인해 인증 흐름이 멈추고 애플리케이션 사용에 영향을 줄 수 있습니다. 이 섹션에서는 오류 응답을 해석하고, 실패한 교환을 추적하며, 헬프데스크에 문의가 들어오기 전에 문제를 해결하는 방법을 안내합니다.

기본을 넘어, 서버 간 앱 통신, IoT 기기 로그인, 더 강력한 프로토콜 보장이 필요한 경우처럼 일부 시나리오에서는 전용 OAuth 확장 기능이나 비대화형 흐름이 필요합니다. 서비스 계정, 상호 TLS, 기기 코드 흐름은 이러한 요구 사항을 위해 설계되었습니다.

일반적인 실패 사례와 고급 사용 사례에 대한 안내를 따르면, 앱 생태계가 복잡해지더라도 견고한 OAuth 솔루션을 문제 해결하고 설계하며 유지 관리할 수 있는 역량을 갖추게 됩니다.

까다로운 토큰 엔드포인트 오류를 추적하든, 입력 장치가 제한적인 기기와 헤드리스 서비스가 곳곳에 있는 실제 환경에 앱을 대비시키든, 이 내용이 통합을 원활하고 안전하게 유지하는 데 도움이 될 것입니다.

OAuth 오류 응답 해석 및 코드 교환 실패

• 잘못된 리디렉션 URI: 리디렉션이 등록된 목록과 일치하지 않을 때 발생합니다. 입력값과 대소문자를 다시 확인하십시오.
• 만료된 권한 부여 코드: 사용자가 너무 오래 걸리거나 코드를 재사용할 때 발생합니다. 코드는 한 번만 사용하고, 받은 직후 빠르게 사용하십시오.
• 일치하지 않는 클라이언트 자격 증명: 잘못된 비밀 값이나 인증서가 제공되었습니다. 필요에 따라 자격 증명을 확인하고 교체하십시오.
• 잘못된 스코프 또는 리소스: 요청한 API 또는 스코프가 허용되지 않았거나 오타가 있습니다. 구성과 앱 권한을 확인하십시오.

서비스 계정, 입력 제한 장치, OAuth 확장

• 서비스 계정(클라이언트 자격 증명 흐름): 사용자 없이 앱이 인증할 수 있도록 합니다. 자동화 및 서버 간 작업에 적합합니다.
• 기기 코드 흐름: 스마트 TV와 IoT 기기용입니다. 다른 기기에서 사용자에게 로그인을 요청하며, 사용 가능한 브라우저가 없는 환경에 적합합니다.
• 상호 TLS 확장: 서버와 클라이언트 모두 인증서를 사용하여 민감한 연동의 보안을 강화하고, 애플리케이션이 강력한 인증 방식을 사용하도록 보장합니다.
• 동적 클라이언트 등록: 대규모 SaaS 또는 멀티 테넌트 시스템에서 앱 온보딩을 자동화하여, 규모가 커져도 자격 증명 관리를 간단하게 해줍니다.

Entra ID의 앱 등록 및 OAuth 가이드

장점

• 중앙 집중식 ID 관리: Microsoft Entra ID와 통합되어 여러 서비스에서 사용자와 앱의 ID를 일관되게 관리할 수 있습니다.
• 강력한 보안 제어: OAuth 2.0, OpenID Connect, 조건부 액세스, 세분화된 권한(범위 및 역할)을 지원합니다.
• 업계 표준 프로토콜: 널리 지원되는 OAuth/OIDC 표준을 활용하므로 타사 도구 및 라이브러리와의 상호 운용성이 높아집니다.
• 상세한 앱 구성: 구성 가능한 리디렉션 URI, 인증서 및 암호, API 권한, 앱 브랜딩 옵션을 설정할 수 있습니다.
• 세분화된 동의 모델: 위임된 권한과 애플리케이션 권한을 지원하며, 관리자 동의 흐름을 통해 과도한 권한을 가진 앱을 제한할 수 있습니다.
• 엔터프라이즈 기능: 멀티 테넌트 앱, B2B 협업, Microsoft 365 및 Azure 서비스와의 통합을 지원합니다.
• 모니터링 및 감사: 앱 등록과 OAuth 흐름에 대한 기본 제공 로그, 로그인 기록, 감사 추적을 제공하여 규정 준수와 문제 해결에 도움이 됩니다.
• 개발자 도구 및 SDK: 광범위한 Microsoft ID 플랫폼 SDK, 문서, 빠른 시작 샘플을 제공하여 구현을 간소화합니다.

단점

• 초보자에게는 복잡함: 구성 및 권한 모델(리디렉션 URI, 회신 URL, 암시적 흐름과 권한 부여 코드 흐름, 범위 등)이 새로운 개발자에게는 혼란스러울 수 있습니다.
• 보안 기능의 가파른 학습 곡선: 조건부 액세스, 관리 ID, 고급 토큰 설정을 안전하게 구성하려면 더 깊은 보안 지식이 필요합니다.
• 권한 확산 위험: 부적절한 동의나 광범위한 앱 권한은 정기적으로 검토하지 않으면 과도한 권한을 가진 앱으로 이어질 수 있습니다.
• 토큰 관리의 세부 사항: 새로 고침 토큰, 토큰 수명, 토큰 취소를 처리하는 방식은 플랫폼마다 동작이 달라 통합 문제를 일으킬 수 있습니다.
• 테넌트 경계 고려 사항: 멀티 테넌트 앱의 동작과 관리자 동의 메시지는 테넌트 간 시나리오에서 운영 복잡성을 높입니다.
• UI 및 용어 변경: Microsoft는 Entra UI와 명칭(Azure AD → Entra ID)을 주기적으로 업데이트하므로, 문서와 실제 화면이 맞지 않아 혼란이 생길 수 있습니다.
• Microsoft 생태계 의존성: Entra ID 기능에 강하게 결합되어 있어, 비 Microsoft ID 공급자로 이전하려면 재작업이 필요할 수 있습니다.
• 잘못된 구성 가능성: 잘못된 앱 등록 설정(예: 리디렉션 URI, 회신 URL, 암시적 흐름 설정)은 보안 허점을 만들거나 인증 흐름을 깨뜨릴 수 있습니다.

OAuth 성공을 위한 다음 단계와 핵심 커뮤니티 리소스

OAuth가 설정되어 정상적으로 동작하고 있더라도 아직 방심하면 안 됩니다. 토큰을 얻는 애플리케이션이 올바르게 구성되었는지 확인하세요. 기본 설정을 연결하는 것은 첫 단계일 뿐입니다. 앱을 돋보이게 하고 사용자를 안전하게 보호하고 싶다면 이제 추가 기능을 살펴볼 때입니다. 고급 클라이언트 라이브러리를 살펴보고, Microsoft Graph를 실험하고, 통합을 더 강력하고 모든 사용자에게 더 원활하게 만들어 줄 새로운 ID 기능을 살펴보세요.

이 작업을 혼자서 해결할 필요도 없습니다. Microsoft Entra ID 문서는 Lake Michigan만큼 깊이가 있으며, 최신 가이드, 코드 샘플, 그리고 곁에 두고 싶은 기술 사양이 가득합니다. 특히 OAuth와 클라우드 ID 표준이 계속 변화하고 있으므로 업데이트를 자주 확인하는 습관을 들이세요.

앱 등록이 만족스러우신가요? 좋습니다. 이제 현장의 다른 사람들이 어떻게 창의적으로 활용하는지 살펴보세요. 개발자 포럼, 공식 토론 게시판, 그리고 인증 라이브러리의 GitHub 저장소도 둘러보세요. 막히는 부분이 있다면 다른 누군가가 이미 같은 문제를 해결했거나, 적어도 그 문제를 크게 불평해 누군가 답변을 달았을 가능성이 높습니다.

직접 시도해 보며 배우는 것을 좋아하신다면, 무료 평가판, 테스트 테넌트, 공개 미리 보기 기능을 확인해 보세요. 이를 통해 실제 사용자에게 변경 사항을 적용하기 전에 안전한 환경에서 여러 가지를 시험해 보고 무엇이 효과적인지 알아볼 수 있습니다. 그리고 OAuth와 보안은 커뮤니티가 함께 만들어 가는 영역이라는 점을 잊지 마세요. 여러분의 성공 사례와 질문을 공유하면 생태계 전체가 건전하게 성장하고, OAuth 흐름을 모두가 더 잘 이해하는 데 도움이 됩니다.

Entra ID 앱 등록 및 OAuth 가이드 체크리스트

• 애플리케이션 유형 및 액세스 모델 계획 — 단일 테넌트, 멀티 테넌트, 개인 Microsoft 계정 중에서 선택하고, SPA, 웹 앱, 모바일, 데몬, 서비스 앱 중 어떤 유형인지 결정합니다.
• Entra ID에 애플리케이션 등록 - 명확한 이름과 지원되는 계정 유형을 지정하여 새 앱 등록을 만듭니다.
• 리디렉션 URI 구성 - 각 플랫폼에 맞는 리디렉션 및 콜백 URI를 추가합니다(https, 사용자 지정 스킴, 개발용 localhost 등).
• 애플리케이션 플랫폼 설정 - SPA, 웹, 모바일 및 데스크톱 플랫폼 옵션을 활성화하고, 필요에 따라 암시적 흐름과 권한 부여 흐름을 구성합니다.
• 클라이언트 암호 생성 및 관리 - 기밀 클라이언트용 클라이언트 암호를 생성하고, 만료 기한을 확인한 뒤 Key Vault에 안전하게 보관합니다.
• 인증에 인증서 사용 - 장기간 유효한 암호 대신 프로덕션 기밀 클라이언트에 공개 키 인증서를 업로드합니다.
• API 권한 구성 - 앱에 필요한 Microsoft Graph 또는 사용자 지정 API 범위와 권한을 추가합니다.
• 필요한 경우 관리자 동의 부여 - 테넌트 전체 동의가 필요한 위임된 권한에 대해 관리자 동의를 요청하고 기록합니다.
• (API인 경우) 사용자 지정 범위 정의 및 노출 - "API 노출"에서 범위 이름, 설명, 관리자 동의 표시 이름을 정의합니다.
• 필요한 경우 앱 역할 설정 - 역할 기반 액세스 제어를 위해 애플리케이션 역할과 위임된 역할을 정의하고, 사용자, 그룹 또는 클라이언트 앱에 할당합니다.
• API를 호출하는 SPA를 위한 CORS 구성 - API에 허용 원본을 추가하거나 게이트웨이 또는 CORS 정책을 구성합니다.
• OAuth 2.0 흐름 선택 - 상황에 맞게 인증 코드 흐름(공개 클라이언트는 PKCE 포함), 데몬 앱용 클라이언트 자격 증명 흐름, 디바이스 코드 흐름 중에서 선택합니다.
• 공개 클라이언트에 PKCE 구현 - 코드 가로채기를 방지하기 위해 SPA와 네이티브 앱에 Proof Key for Code Exchange를 적용합니다.
• 토큰을 올바르게 검증 - Microsoft ID 라이브러리 또는 JWT 검증 로직을 사용하여 발급자, 대상(audience), 서명, 만료 시간, 필수 클레임을 확인합니다.
• Microsoft 인증 라이브러리(MSAL) 사용 - 토큰 획득, 캐싱, 갱신, 플랫폼 간 안전한 처리를 위해 MSAL을 우선적으로 사용합니다.
• 조건부 액세스 및 MFA 구성(필요한 경우) - 앱 등록 또는 사용자 로그인 흐름에 정책을 적용하여 보안 통제를 강제합니다.
• 로그인 및 감사 로그 모니터링 - 로깅을 활성화하고 Entra ID 로그에서 로그인 이벤트, 동의, 관리 작업을 검토합니다.
• 최소 권한 원칙 적용 - 필요한 권한만 요청하고, 노출을 최소화하기 위해 점진적 동의를 우선 사용합니다.
• 암호와 인증서를 정기적으로 교체 - 만료 예정 자격 증명에 대해 자동 교체와 알림을 구현합니다.
• 클라이언트 측 코드와 저장소 보호 - 클라이언트 앱에 암호를 저장하지 않도록 하고, 안전한 저장소와 플랫폼 모범 사례를 사용합니다.
• 개발 및 스테이징 환경에서 로그인과 토큰 흐름 테스트 - 인증 흐름, 토큰 수명, 갱신 로직, 오류 처리, 동의 UX를 검증합니다.
• 사용자와 관리자를 위한 문서 준비 - 동의 단계, 필요한 권한, 문제 해결 안내를 포함합니다.
• 앱 등록을 주기적으로 검토 및 업데이트 - 권한, 역할, 암호, 등록 내역을 감사하여 오래되었거나 사용되지 않는 앱을 찾아냅니다.
• 네트워크 및 API 보호 적용 - 백엔드 API를 보호하기 위해 API Management, WAF, 속도 제한, 서비스 엔드포인트를 검토합니다.

Azure 액세스 토큰 사용 OAuth 인증

앱 등록 & OAuth 가이드란 무엇이며 왜 중요한가요?

앱 등록 & OAuth 가이드는 ID 공급자(예: Azure)에 클라이언트 애플리케이션을 등록하고, 애플리케이션이 보호된 리소스에 안전하게 액세스를 요청할 수 있도록 OAuth 2.0 권한 부여 흐름을 구현하는 방법을 설명합니다. 웹 애플리케이션, 단일 페이지 앱, 데스크톱 앱, 웹 서버 백엔드 중 무엇을 만들든 이는 매우 중요합니다. 애플리케이션은 액세스 토큰을 얻기 위해 앱 ID 또는 애플리케이션 ID, 클라이언트 ID, 그리고 기밀 클라이언트의 경우 클라이언트 암호가 필요하며, 상황에 따라 ID 토큰도 받을 수 있어야 하기 때문입니다.

Azure 앱을 등록하고 애플리케이션 ID와 앱 ID를 얻으려면 어떻게 해야 하나요?

Azure 앱을 등록하려면 Azure Portal로 이동해 새 앱 등록을 만들고, 이름과 리디렉션 URI를 입력한 뒤, 애플리케이션 개요에 표시되는 클라이언트 ID(애플리케이션 ID)를 확인합니다. 애플리케이션이 기밀 클라이언트(웹 서버 또는 전통적인 웹 앱)라면 클라이언트 ID와 함께 사용할 클라이언트 암호를 생성합니다. 이렇게 등록된 애플리케이션은 권한 부여에 사용되며, Microsoft 서비스에 액세스 토큰을 요청하는 데 쓰입니다.

단일 페이지 앱(SPA)에는 어떤 OAuth 2.0 권한 부여 흐름을 사용해야 하나요?

싱글 페이지 앱(SPA)은 암시적 흐름(implicit flow) 대신 PKCE(Proof Key for Code Exchange)를 적용한 권한 부여 코드 흐름(authorization code grant)을 사용해야 합니다. 이렇게 하면 토큰을 얻는 애플리케이션이 안전하게 동작합니다. PKCE를 적용한 코드 흐름을 사용하면 브라우저 기반 클라이언트에서도 애플리케이션이 코드를 액세스 토큰으로 안전하게 교환할 수 있으며, 싱글 페이지 앱이 브라우저에 클라이언트 비밀(client secret)을 노출하지 않고 OAuth를 사용할 수 있습니다.

권한 부여 요청은 어떻게 동작하며, 어떤 매개 변수가 필요합니까?

권한 부여 요청은 ID 공급자의 권한 부여 엔드포인트로 전송되며, 일반적으로 client_id(앱 ID), response_type(예: code), redirect_uri, scope, state를 포함합니다. PKCE를 적용한 코드 흐름을 사용하는 싱글 페이지 앱은 code_challenge와 code_challenge_method도 함께 포함합니다. 사용자가 인증하고 동의(OAuth 동의)하면 권한 부여 서버는 리디렉션 URI로 코드를 반환하며, 애플리케이션은 이 코드를 액세스 토큰으로 교환할 수 있습니다.

액세스 토큰 교환(코드를 액세스 토큰으로 교환)은 코드로 어떻게 구현합니까?

권한 부여 코드를 받은 후 클라이언트 애플리케이션은 토큰 엔드포인트로 요청을 보냅니다. 이 요청에는 code, client_id(기밀 클라이언트의 경우 client_secret 포함), redirect_uri, grant_type=authorization_code가 포함됩니다. PKCE를 사용하는 경우에는 code_verifier도 포함합니다. 토큰 엔드포인트는 액세스 토큰, 요청된 경우 ID 토큰, 그리고 액세스 토큰이 만료되었을 때 새 액세스 토큰을 얻기 위한 갱신 토큰(refresh token)을 응답으로 반환할 수 있습니다.

액세스 토큰은 어떻게 얻고, 이를 사용해 API를 호출합니까?

선택한 OAuth 2.0 권한 부여 흐름을 완료하고 토큰 엔드포인트를 호출하여 액세스 토큰을 얻습니다. 액세스 토큰을 확보한 후에는 Microsoft 서비스나 기타 API(예: Google 캘린더 또는 사용자 지정 API)를 호출할 때 Authorization 헤더에 Bearer 형식으로 전송합니다. 애플리케이션의 요청이 승인되었는지 확인하려면 웹 서버나 리소스 측에서 토큰을 검증하십시오.

액세스 토큰이 만료되면 어떻게 해야 하며, 새 갱신 토큰은 어떻게 얻습니까?

액세스 토큰이 만료되면 갱신 토큰이 제공된 경우 grant_type=refresh_token을 사용하여 토큰 엔드포인트에 새 액세스 토큰을 요청합니다. 일부 흐름이나 공급자는 갱신 시 새 갱신 토큰을 발급하고, 다른 경우에는 같은 갱신 토큰을 그대로 재사용할 수 있습니다. 갱신 토큰을 사용할 수 없는 경우(퍼블릭 클라이언트나 수명이 짧은 흐름)에는 사용자를 앱으로 다시 보내 새 권한 부여 요청을 수행하도록 해야 합니다.

웹 애플리케이션과 모바일 또는 데스크톱 앱에 각각 별도의 앱 등록이 필요합니까?

리디렉션 URI, 클라이언트 비밀, 허용되는 흐름이 서로 다르기 때문에 기존 웹 서버 앱, 싱글 페이지 앱, 데스크톱 앱처럼 애플리케이션 유형이 크게 다른 경우에는 보통 별도의 앱 등록이 필요합니다. 앱 유형별로 등록을 나누면 각 유형에 맞는 권한 부여 흐름과 리디렉션 URI를 구성할 수 있습니다.

클라이언트 앱 등록과 테넌트 내 애플리케이션은 어떻게 다릅니까?

클라이언트 앱 등록은 ID 공급자에 있는 특정 등록 항목(Azure 앱)을 의미하며, 리디렉션 URI와 비밀 같은 구성 정보를 보관합니다. 테넌트 내 애플리케이션은 해당 등록이 특정 Azure AD 테넌트에 존재하며, 그 테넌트 안에서 역할과 권한을 할당받을 수 있다는 것을 뜻합니다. 단일 앱 등록은 필요에 따라 멀티 테넌트 또는 싱글 테넌트로 구성할 수 있습니다.

Microsoft 서비스에 액세스를 요청하려면 어떻게 해야 하며, 어떤 권한이 필요합니까?

권한 부여 요청에 애플리케이션에 필요한 스코프를 지정하여 액세스를 요청합니다. Microsoft 서비스의 경우 Azure 앱 등록에서 API 권한을 구성한 다음, 사용자에게 동의(OAuth 동의)를 요청하거나 관리자가 테넌트 전체에 대한 동의를 부여하도록 합니다. 애플리케이션은 애플리케이션 요청에 따라 User.Read나 사용자 지정 API 스코프 같은 스코프를 요청하며, 액세스 토큰을 사용해 서비스를 호출합니다.

싱글 페이지 앱에서 클라이언트 비밀을 안전하게 관리하고 자격 증명 유출을 막으려면 어떻게 해야 합니까?

브라우저에서 실행되는 코드는 검사될 수 있으므로 싱글 페이지 앱은 클라이언트 비밀을 저장하면 안 됩니다. PKCE를 적용한 권한 부여 코드 흐름을 사용하면 클라이언트 비밀 없이도 애플리케이션이 액세스 토큰을 안전하게 얻을 수 있습니다. 기밀 앱(웹 서버)의 경우 클라이언트 ID와 클라이언트 비밀은 사용자에게 노출되지 않도록 서버 측에 보관해야 합니다.

리디렉션 URI의 역할은 무엇이며, 왜 앱 등록의 값과 일치해야 합니까?

리다이렉트 URI는 ID 공급자가 권한 부여 응답(코드 또는 토큰)을 보내는 위치입니다. 권한 부여 응답 하이재킹을 막으려면 앱 등록에 등록된 리다이렉트 URI와 일치해야 합니다. 공급자가 정의한 정확한 일치 방식이나 허용된 패턴을 사용하십시오. 일치하지 않으면 토큰 교환이 실패합니다.

사용자가 액세스 토큰과 함께 ID 토큰도 받도록 인증하려면 어떻게 해야 하나요?

ID 토큰을 받으려면 openid 범위를 요청하고, ID 토큰 발급을 트리거하는 response_type을 포함해야 합니다(openid를 사용하는 권한 부여 코드 흐름). ID 토큰에는 인증된 사용자에 대한 ID 클레임이 들어 있습니다. ID 토큰은 클라이언트 애플리케이션에 사용자를 로그인시키는 데 사용하고, 액세스 토큰은 다운스트림 API를 호출하는 데 사용하십시오.

기존 웹과 단일 페이지 앱(SPA)에는 각각 어떤 권한 부여 흐름이 적용되나요?

기존 웹 애플리케이션(서버 측)은 일반적으로 클라이언트 자격 증명(클라이언트 ID와 클라이언트 암호)을 사용하는 권한 부여 코드 흐름을 사용하며, 웹 서버에서 코드를 교환합니다. 단일 페이지 앱은 클라이언트 암호 없이 PKCE를 사용하는 권한 부여 코드 부여 방식을 사용합니다. 데스크톱 앱도 PKCE를 사용합니다. 애플리케이션 유형과 비밀 정보를 안전하게 저장할 수 있는 위치를 기준으로 흐름을 선택하십시오.

하나의 앱 등록을 여러 클라이언트 애플리케이션에 사용할 수 있나요, 아니면 앱마다 앱 등록을 하나씩 만들어야 하나요?

여러 클라이언트 애플리케이션이 동일한 구성과 리다이렉트 URI를 공유한다면 앱 등록 하나를 여러 애플리케이션에 사용할 수 있습니다. 다만 권한, 리다이렉트 URI, 수명 주기 관리를 분리하기 위해 서로 다른 애플리케이션마다 별도의 앱 등록(separate app registrations)을 만드는 것이 권장되는 경우가 많습니다. 애플리케이션마다 다른 권한 범위가 필요한지, 관리자 동의 동작이 다른지도 함께 고려하십시오.

웹 서버나 API에서 토큰은 어떻게 검증하나요?

웹 서버나 API는 액세스 토큰 또는 ID 토큰의 서명, 발급자(issuer), 대상(audience, 앱 ID 또는 애플리케이션 ID), 만료 시간을 검증해야 합니다. 서명 키를 얻으려면 공급자의 검색 문서(discovery document)를 사용하고, 플랫폼에 맞는 검증 라이브러리를 권장 방식에 따라 사용하십시오. 이렇게 검증해야 인증되고 권한이 부여된 애플리케이션의 요청만 수락됩니다.

클라이언트 자격 증명을 사용해 백엔드 서비스용 액세스 토큰을 요청하는 절차는 어떻게 되나요?

서버 간(server-to-server) 시나리오에서는 Azure 앱을 등록하고 애플리케이션 권한을 부여한 다음 클라이언트 자격 증명 흐름을 사용합니다. 토큰 엔드포인트에 grant_type=client_credentials, client_id, client_secret, 그리고 scope 또는 resource를 담아 POST 요청을 보냅니다. 토큰 엔드포인트는 백엔드가 Microsoft 서비스나 보호된 API를 호출하는 데 사용할 수 있는 액세스 토큰을 반환합니다.

멀티 테넌트 애플리케이션에서 OAuth 동의와 관리자 동의는 어떻게 처리하나요?

앱이 멀티 테넌트로 등록되어 있으면 다른 테넌트의 사용자도 권한 부여 요청 중에 위임된 권한에 동의할 수 있습니다. 관리자 동의가 필요한 권한은 관리자가 자신의 테넌트에 대해 동의를 부여해야 합니다. 테넌트 관리자가 OAuth 동의를 대규모로 부여할 수 있도록 안내 내용과 동의 URL을 함께 제공하십시오.

권한 부여 요청이 실패하면 어떤 순서로 문제를 해결해야 하나요?

Microsoft 포털에 앱이 등록되어 있는지, 리다이렉트 URI가 일치하는지, 클라이언트 ID와 암호가 올바른지, 범위가 유효한지, 그리고 (사용하는 경우) 권한 부여 유형과 PKCE 매개 변수가 올바른지 확인하십시오. 권한 부여 엔드포인트나 토큰 엔드포인트가 반환한 오류 메시지를 확인하고, 클라이언트와 서버 양쪽의 로그를 살펴보십시오. 특정 오류 코드는 Stack Overflow와 공급자 문서에서 도움을 얻을 수 있습니다.

Google 캘린더 같은 타사 API를 등록한 앱과 어떻게 통합할 수 있나요?

Google 캘린더나 기타 타사 API와 통합하려면 해당 공급자가 요구하는 OAuth 2.0 권한 부여 흐름을 구현해야 합니다. 애플리케이션은 타사 API에 맞는 올바른 범위를 요청하고, 별도의 토큰 수명 주기를 처리해야 합니다. 공급자마다 별도의 클라이언트 애플리케이션 등록이 필요할 수 있으며, 각 서비스의 액세스 토큰 획득을 조율해야 합니다.

디바이스 코드 흐름이나 특정 장치용 특수 흐름은 언제 사용해야 하나요?

브라우저를 사용할 수 없고 입력이 제한된 장치에는 디바이스 코드 흐름을 사용하십시오. 디바이스 흐름에서는 사용자가 다른 장치에서 확인 URL에 접속해 인증할 수 있습니다. 이는 코드 부여, 클라이언트 자격 증명, 새로 고침 토큰 흐름과 함께 지원되는 특수 권한 부여 흐름 중 하나로, 다양한 형태의 애플리케이션을 수용하기 위해 제공됩니다.