Azure Active Directory B2C의 OAuth 2.0 권한 부여 코드 흐름

디바이스에 설치된 앱에서 OAuth 2.0 인증 코드 부여를 사용하여 웹 API와 같은 보호된 리소스에 액세스할 수 있습니다. OAuth 2.0의 Azure AD B2C(Azure Active Directory B2C) 구현을 사용하여 단일 페이지, 모바일 및 데스크톱 앱에 등록, 로그인 및 기타 ID 관리 작업을 추가할 수 있습니다. 이 문서에서는 오픈 소스 라이브러리를 사용하지 않고 HTTP 메시지를 보내고 받는 방법을 설명합니다. 이 문서는 언어 독립적입니다. 가능한 경우 지원되는 MSAL(Microsoft 인증 라이브러리)을 사용하는 것이 좋습니다. MSAL사용하는 샘플 앱을 살펴보세요.

OAuth 2.0 인증 코드 흐름은 OAuth 2.0 사양의 섹션 4.1에서 설명합니다. 웹 애플리케이션, 단일 페이지 애플리케이션 및 기본적으로 설치된 애플리케이션을 포함하여 대부분의 애플리케이션 형식에서 인증 및 권한 부여에 사용할 수 있습니다. OAuth 2.0 권한 부여 코드 흐름을 사용하여 애플리케이션에 대한 액세스 토큰 및 새로 고침 토큰을 안전하게 획득할 수 있습니다. 이 토큰은 권한 부여 서버에서 보호하는 리소스에 액세스하는 데 사용할 수 있습니다. 새로 고침 토큰을 사용하면 일반적으로 1시간 후 액세스 토큰이 만료되면 클라이언트가 새 액세스(및 새로 고침) 토큰을 획득할 수 있습니다.

이 문서에서는 공용 클라이언트 OAuth 2.0 권한 부여 코드 흐름에 중점을 둡니다. 공용 클라이언트는 비밀 암호의 무결성을 안전하게 기본 신뢰할 수 없는 클라이언트 애플리케이션입니다. 여기에는 단일 페이지 애플리케이션, 모바일 앱, 데스크톱 애플리케이션 및 기본적으로 서버에서 실행되지 않는 애플리케이션이 포함됩니다.

참고 항목

Azure AD B2C를 사용하여 ID 관리를 웹앱에 추가하려면 OAuth 2.0 대신 OpenID Connect를 사용합니다.

Azure AD B2C는 표준 OAuth 2.0 흐름을 확장하여 간단한 인증 및 권한 부여 이상의 작업을 수행합니다. 사용자 흐름을 소개합니다. 사용자 흐름을 사용하면 OAuth 2.0을 사용하여 등록, 로그인 및 프로필 관리와 같은 사용자 환경을 애플리케이션에 추가할 수 있습니다. OAuth 2.0 프로토콜을 사용하는 ID 공급자에는 Amazon, Microsoft Entra ID, Facebook, GitHub, GoogleLinkedIn이 포함됩니다.

이 문서에서 HTTP 요청을 시도하려면 다음을 수행합니다.

  1. Azure AD B2C 테넌트 이름으로 바꿉 {tenant} 다.
  2. 이전에 Azure AD B2C 테넌트에 등록한 애플리케이션의 앱 ID로 바꿉 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 니다.
  3. 예를 들어 b2c_1_sign_in테넌트에서 만든 정책의 이름으로 바꿉 {policy} 다.

단일 페이지 앱에 필요한 리디렉션 URI 설정

단일 페이지 애플리케이션에 대한 인증 코드 흐름에는 몇 가지 추가 설정이 필요합니다. 단일 페이지 애플리케이션 만들기에 관한 지침에 따라 리디렉션 URI를 CORS에 사용하도록 설정된 것으로 올바르게 표시합니다. CORS를 사용하도록 기존 리디렉션 URI를 업데이트하려면 앱 등록인증 탭에 있는 "웹" 섹션에서 마이그레이션 프롬프트를 클릭하면 됩니다. 또는 앱 등록 매니페스트 편집기를 열고 replyUrlsWithType 섹션에서 리디렉션 URI에 대한 type 필드를 spa로 설정할 수 있습니다.

spa 리디렉션 형식은 암시적 흐름과 이전 버전과 호환됩니다. 현재 암시적 흐름을 사용하여 토큰을 가져오는 앱은 이슈 없이 spa 리디렉션 URI 형식으로 이동하고 암시적 흐름을 계속 사용할 수 있습니다.

1. 권한 부여 코드 가져오기

인증 코드 흐름은 클라이언트가 사용자를 /authorize 엔드포인트로 보내는 것으로 시작됩니다. 사용자가 조치를 취하는 흐름의 대화형 부분입니다. 이 요청에서 클라이언트는 매개 변수에 scope 사용자로부터 획득해야 하는 권한을 나타냅니다. 다음 예제(가독성을 위해 줄 바꿈 포함)는 권한 부여 코드를 획득하는 방법을 보여 줍니다. 이 GET HTTP 요청을 테스트하는 경우 해당 브라우저를 사용합니다.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
매개 변수 필수? 설명
{tenant} Required Azure AD B2C 테넌트 이름
{policy} Required 실행할 사용자 흐름입니다. Azure AD B2C 테넌트에서 만든 사용자 흐름의 이름을 지정합니다. 예: b2c_1_sign_in, b2c_1_sign_up 또는 b2c_1_edit_profile.
client_id Required Azure Portal에서 앱에 할당된 애플리케이션 ID입니다.
response_type Required 응답 유형입니다. 인증 코드 흐름의 경우 code를 포함해야 합니다. ID 토큰을 응답 형식(예: code+id_token)에 포함하면 받을 수 있으며, 이 경우 범위에 openid를 포함해야 합니다.
redirect_uri Required 앱에서 인증 응답을 보내고 받는 앱의 리디렉션 URI입니다. URL로 인코딩되어야 한다는 점을 제외하고 포털에 등록한 리디렉션 URI 중 하나와 정확히 일치해야 합니다.
scope Required 공백으로 구분된 범위 목록입니다. 범위는 openid 사용자에게 로그인하고 ID 토큰 형식으로 사용자에 대한 데이터를 가져올 수 있는 권한을 나타냅니다. 범위는 offline_access 웹 애플리케이션에 대해 선택 사항입니다. 리소스에 대한 확장된 액세스를 위해 애플리케이션에 새로 고침 토큰이 필요했음을 나타냅니다. client-id는 발급된 토큰이 Azure AD B2C 등록 클라이언트에서 사용하기 위한 것임을 나타냅니다. 웹 https://{tenant-name}/{app-id-uri}/{scope} API와 같은 보호된 리소스에 대한 사용 권한을 나타냅니다. 자세한 내용은 액세스 토큰 요청을 참조하세요.
response_mode 권장 결과 권한 부여 코드를 앱에 다시 보내는 데 사용하는 방법입니다. 또는 .form_postfragmentquery수 있습니다.
state 권장 사용하려는 콘텐츠의 문자열이 될 수 있는 요청에 포함된 값입니다. 일반적으로 교차 사이트 요청 위조 공격을 방지하기 위해 임의로 생성된 고유 값이 사용됩니다. 또한 state(상태)는 인증 요청이 발생하기 전에 앱에서 사용자 상태에 대한 정보를 인코딩하는 데에도 사용됩니다. 예를 들어 사용자가 보고 있던 페이지 또는 실행 중이었던 사용자 흐름입니다.
prompt 선택 사항 필요한 사용자 상호 작용의 유형입니다. 현재 유효한 값은 사용자가 해당 요청에 자격 증명을 입력하도록 강제하는 값뿐입니다 login. Single Sign-On은 적용되지 않습니다.
code_challenge 권장/필수 PKCE(코드 교환용 증명 키)를 통해 권한 부여 코드 부여를 보호하는 데 사용됩니다. code_challenge_method가 포함되면 필수입니다. code_verifiercode_challenge를 생성하려면 애플리케이션에 논리를 추가해야 합니다. code_challengecode_verifier의 Base64 URL로 인코딩된 SHA256 해시입니다. 나중에 사용하기 위해 애플리케이션에 code_verifier를 저장하고 권한 부여 요청과 함께 code_challenge를 보냅니다. 자세한 내용은 PKCE RFC를 참조하세요. 이제 모든 애플리케이션 유형(네이티브 앱, SPA 및 웹앱과 같은 기밀 클라이언트)에서 권장됩니다.
code_challenge_method 권장/필수 code_challenge 매개 변수에 대한 code_verifier를 인코딩하는 데 사용되는 메서드입니다. 이렇게 해야S256하지만 어떤 이유로 클라이언트에서 SHA256을 지원할 수 없는 경우 사양을 사용할 plain 수 있습니다.

code_challenge_method를 제외하지만 여전히 code_challenge를 포함하는 경우 code_challenge는 일반 텍스트로 간주됩니다. Microsoft ID 플랫폼은 plainS256을 모두 지원합니다. 자세한 내용은 PKCE RFC를 참조하세요. 이는 권한 부여 코드 흐름을 사용하는 단일 페이지 앱에 필요합니다.
login_hint 아니요 로그인 페이지의 로그인 이름 필드를 미리 채우는 데 사용할 수 있습니다. 자세한 내용은 로그인 이름 미리 채워기를 참조 하세요.
domain_hint 아니요 로그인에 사용해야 하는 소셜 ID 공급자에 대한 힌트를 Azure AD B2C에 제공합니다. 유효한 값이 포함된 경우 사용자는 ID 공급자 로그인 페이지로 직접 이동합니다. 자세한 내용은 소셜 공급자에 대한 로그인 리디렉션을 참조하세요.
사용자 지정 매개 변수 아니요 사용자 지정 정책과 함께 사용할 수 있는 사용자 지정 매개 변수입니다. 예를 들어 동적 사용자 지정 페이지 콘텐츠 URI또는 키-값 클레임 해결 프로그램입니다.

이 시점에서 사용자에게 사용자 흐름의 워크플로를 완료하라는 메시지가 표시됩니다. 이 경우 사용자 이름과 암호를 입력하거나, 소셜 ID로 로그인하거나, 디렉터리를 등록하거나, 다른 단계를 수행할 수도 있습니다. 사용자 작업은 사용자 흐름이 정의되는 방식에 따라 달라집니다.

사용자가 사용자 흐름을 완료하면 Microsoft Entra ID에서 앱에 대한 응답을 redirect_uri에 사용한 값으로 반환합니다. 매개 변수에 지정된 메서드를 response_mode 사용합니다. 응답은 실행된 사용자 흐름과 관계없이 각 사용자 작업 시나리오에 대해 정확히 동일합니다.

사용하는 response_mode=query 성공적인 응답은 다음과 같습니다.

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
매개 변수 설명
코드 앱이 요청한 권한 부여 코드입니다. 앱에서는 권한 부여 코드를 사용하여 대상 리소스에 대한 액세스 토큰을 요청할 수 있습니다. 인증 코드는 수명이 매우 짧습니다. 일반적으로 약 10분 후에 만료됩니다.
state 이전 섹션의 표에서 전체 설명을 참조하세요. state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 앱에서 요청 및 응답의 state 값이 동일한지 확인해야 합니다.

앱에서 적절하게 처리할 수 있도록 오류 응답을 리디렉션 URI로 보낼 수도 있습니다.

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 오류 코드 문자열입니다. 문자열을 사용하여 오류에 대응할 수도 있습니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다.
state 잎의 표에 나와 있는 전체 설명을 참조하세요. state 매개 변수가 요청에 포함된 경우 동일한 값이 응답에 표시됩니다. 앱에서 요청 및 응답의 state 값이 동일한지 확인해야 합니다.

2. 액세스 토큰 가져오기

이제 권한 부여 코드를 획득했으므로 엔드포인트에 POST 요청을 /token 전송하여 토큰을 원하는 리소스에 사용할 code 수 있습니다. Azure AD B2C에서는 요청에 범위를 지정하여 다른 API에 대한 액세스 토큰을 평소와 같이 요청할 수 있습니다.

앱의 클라이언트 ID를 요청된 범위로 사용하는 규칙에 따라 앱의 자체 백 엔드 Web API에 대한 액세스 토큰을 요청할 수도 있습니다(이 경우 해당 클라이언트 ID가 "대상"인 액세스 토큰이 생성됨).

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
매개 변수 필수? 설명
{tenant} Required Azure AD B2C 테넌트 이름
{policy} Required 권한 부여 코드를 획득하는 데 사용된 사용자 흐름입니다. 이 요청에서는 다른 사용자 흐름을 사용할 수 없습니다.
client_id Required Azure Portal에서 앱에 할당된 애플리케이션 ID입니다.
client_secret 예, Web Apps Azure Portal에서 생성한 애플리케이션 암호입니다. 클라이언트 비밀은 클라이언트가 클라이언트 비밀을 안전하게 저장할 수 있는 웹앱 시나리오에 대해 이 흐름에서 사용됩니다. 네이티브 앱(퍼블릭 클라이언트) 시나리오의 경우 클라이언트 암호를 안전하게 저장할 수 없으므로 이 호출에서 사용되지 않습니다. 클라이언트 암호를 사용하는 경우 주기적으로 변경하세요.
grant_type Required 부여 유형입니다. 권한 부여 코드 흐름의 경우 권한 부여 형식은 .이어야 authorization_code합니다.
scope 권장 공백으로 구분된 범위 목록입니다. 단일 범위 값은 Azure AD B2C에 요청되는 사용 권한을 모두 나타냅니다. 클라이언트 ID를 범위로 사용하면 앱에 동일한 클라이언트 ID로 표시되는 사용자 고유의 서비스 또는 웹 API에 대해 사용할 수 있는 액세스 토큰이 필요하다는 것을 나타냅니다. 범위는 offline_access 리소스에 대한 수명이 긴 액세스를 위해 앱에 새로 고침 토큰이 필요하다는 것을 나타냅니다. 범위를 사용하여 openid Azure AD B2C에서 ID 토큰을 요청할 수도 있습니다.
코드 Required /authorize 엔드포인트에서 획득한 인증 코드입니다.
redirect_uri Required 인증 코드를 받은 애플리케이션의 리디렉션 URI입니다.
code_verifier 권장 인증 코드를 얻는 데 사용된 것과 동일한 code_verifier입니다. PKCE를 인증 코드 부여 요청에 사용한 경우에 필요합니다. 자세한 내용은 PKCE RFC를 참조하세요.

이 POST HTTP 요청을 테스트하는 경우 Microsoft PowerShell 또는 Postman과 같은 HTTP 클라이언트를 사용할 수 있습니다.

성공적인 토큰 응답은 다음과 같습니다.

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
매개 변수 설명
not_before 토큰이 유효한 것으로 간주되는 시간(epoch 시간)입니다.
token_type 토큰 형식 값입니다. Microsoft Entra ID가 지원하는 유일한 형식은 Bearer입니다.
access_token 사용자가 요청한 서명된 JWT(JSON Web Token)입니다.
scope 토큰이 유효한 범위입니다. 또한 나중에 사용할 수 있도록 범위를 사용하여 토큰을 캐시할 수도 있습니다.
expires_in 토큰이 유효한 시간(초)입니다.
refresh_token OAuth 2.0 새로 고침 토큰입니다. 앱은 현재 토큰이 만료된 후 이 토큰을 사용하여 추가 토큰을 획득할 수 있습니다. 새로 고침 토큰은 장기적으로 존재합니다. 토큰을 사용하여 오랜 시간 동안 리소스에 대한 액세스를 유지할 수 있습니다. 자세한 내용은 Azure AD B2C 토큰 참조를 참조하세요.

오류 응답은 다음과 같습니다.

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 오류 코드 문자열입니다. 문자열을 사용하여 오류에 대응할 수도 있습니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다.

3. 토큰 사용

액세스 토큰을 성공적으로 획득했으므로 이제 헤더에 토큰을 포함하여 백 엔드 웹 API에 대한 요청에서 토큰을 Authorization 사용할 수 있습니다.

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. 토큰 새로 고침

액세스 토큰 및 ID 토큰은 수명이 짧습니다. 만료되면 새로 고쳐야 리소스에 계속 액세스할 수 있습니다. 액세스 토큰을 새로 고치면 Azure AD B2C는 새 토큰을 반환합니다. 새로 고친 액세스 토큰에는 업데이트된 nbf(이전은 아님), iat(발급 시간) 및 exp(만료) 클레임 값이 있습니다. 다른 모든 클레임 값은 원래 발급된 액세스 토큰과 동일합니다.

토큰을 새로 고치려면 다른 POST 요청을 /token 엔드포인트로 제출합니다. 이번에는 다음 대신 입력 refresh_token 합니다 code.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
매개 변수 필수? 설명
{tenant} Required Azure AD B2C 테넌트 이름
{policy} Required 원래 새로 고침 토큰을 획득하는 데 사용된 사용자 흐름입니다. 이 요청에서는 다른 사용자 흐름을 사용할 수 없습니다.
client_id Required Azure Portal에서 앱에 할당된 애플리케이션 ID입니다.
client_secret 예, Web Apps Azure Portal에서 생성한 애플리케이션 암호입니다. 클라이언트 비밀은 클라이언트가 클라이언트 비밀을 안전하게 저장할 수 있는 웹앱 시나리오에 대해 이 흐름에서 사용됩니다. 네이티브 앱(퍼블릭 클라이언트) 시나리오의 경우 클라이언트 암호를 안전하게 저장할 수 없으므로 이 호출에서 사용되지 않습니다. 클라이언트 암호를 사용하는 경우 주기적으로 변경하세요.
grant_type Required 부여 유형입니다. 권한 부여 코드 흐름의 이 레그의 경우 권한 부여 형식은 .이어야 refresh_token합니다.
scope 권장 공백으로 구분된 범위 목록입니다. 단일 범위 값은 요청 중인 두 가지 권한을 모두 Microsoft Entra ID에 나타냅니다. 클라이언트 ID를 범위로 사용하면 앱에 동일한 클라이언트 ID로 표시되는 사용자 고유의 서비스 또는 웹 API에 대해 사용할 수 있는 액세스 토큰이 필요하다는 것을 나타냅니다. 범위는 offline_access 리소스에 대한 수명이 긴 액세스를 위해 앱에 새로 고침 토큰이 필요하다는 것을 나타냅니다. 범위를 사용하여 openid Azure AD B2C에서 ID 토큰을 요청할 수도 있습니다.
redirect_uri 선택 사항 인증 코드를 받은 애플리케이션의 리디렉션 URI입니다.
refresh_token Required 흐름의 두 번째 단계에서 얻은 원래의 새로 고침 토큰입니다.

성공적인 토큰 응답은 다음과 같습니다.

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
매개 변수 설명
not_before 토큰이 유효한 것으로 간주되는 시간(epoch 시간)입니다.
token_type 토큰 형식 값입니다. Microsoft Entra ID가 지원하는 유일한 형식은 Bearer입니다.
access_token 요청한 서명된 JWT입니다.
scope 토큰이 유효한 범위입니다. 나중에 사용할 수 있도록 범위를 사용하여 토큰을 캐시할 수도 있습니다.
expires_in 토큰이 유효한 시간(초)입니다.
refresh_token OAuth 2.0 새로 고침 토큰입니다. 앱은 현재 토큰이 만료된 후 이 토큰을 사용하여 추가 토큰을 획득할 수 있습니다. 새로 고침 토큰은 수명이 길며 장기간 리소스에 대한 액세스를 유지하는 데 사용할 수 있습니다. 자세한 내용은 Azure AD B2C 토큰 참조를 참조하세요.

오류 응답은 다음과 같습니다.

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
매개 변수 설명
error 발생하는 오류 유형을 분류하는 데 사용할 수 있는 오류 코드 문자열입니다. 문자열을 사용하여 오류에 대응할 수도 있습니다.
error_description 인증 오류의 근본 원인을 식별하도록 도울 수 있는 특정 오류 메시지입니다.

사용자 고유의 Azure AD B2C 디렉터리 사용

이러한 요청을 직접 시도하려면 다음 단계를 완료합니다. 이 문서에서 사용한 예제 값을 사용자 고유의 값으로 바꿉 있습니다.

  1. Azure AD B2C 디렉터리를 만듭니다. 요청에 디렉터리의 이름을 사용합니다.
  2. 애플리케이션 ID 및 리디렉션 URI를 가져오는 애플리케이션을 만듭니다. 앱에 네이티브 클라이언트를 포함합니다.
  3. 사용자 흐름을 만들어 사용자 흐름 이름을 가져옵니다.