인증의 새로운 기능?

  • 아티클

Microsoft는 보안, 사용성 및 표준 준수를 개선하기 위해 Microsoft ID 플랫폼의 기능을 주기적으로 추가 및 수정합니다.

달리 명시되지 않는 한 여기에 설명된 변경 내용은 명시된 변경 발효일 이후에 등록된 애플리케이션에만 적용됩니다.

이 문서를 정기적으로 확인하여 다음에 대해 알아봅니다.

  • 알려진 문제 및 수정 사항
  • 프로토콜 변경 내용
  • 더 이상 사용되지 않는 기능

팁

이 페이지에 대한 업데이트 알림을 받으려면 RSS 피드 판독기에 다음 URL을 추가합니다.
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

2023년 10월

RemoteConnect UX 프롬프트가 업데이트됨

적용 날짜: 2023년 10월

영향을 받는 엔드포인트: v2.0 및 v1.0

영향을 받는 프로토콜: RemoteConnect

RemoteConnect는 기본 새로 고침 토큰과 관련된 Microsoft 인증 브로커 및 Microsoft Intune 관련 시나리오에 사용되는 디바이스 간 흐름입니다. 피싱 공격을 방지하기 위해 RemoteConnect 흐름은 흐름이 성공적으로 완료될 때 원격 디바이스(흐름을 시작한 디바이스)가 조직에서 사용하는 모든 애플리케이션에 액세스할 수 있도록 업데이트된 UX 언어를 수신합니다.

표시되는 프롬프트는 다음과 같습니다.

'조직에서 사용하는 모든 앱에 액세스할 수 있도록 원격 디바이스 또는 서비스에 로그인됩니다.'라는 업데이트된 원격 커넥트 프롬프트의 스크린샷

2023년 6월

확인되지 않은 도메인 소유자에 대한 이메일 클레임 생략

적용 날짜: 2023년 6월.

영향을 받는 엔드포인트: v2.0 및 v1.0

변경

다중 테넌트 애플리케이션의 경우 토큰 페이로드에서 선택적 email 클레임이 요청되면 도메인 소유자가 확인되지 않은 이메일이 기본적으로 생략됩니다.

다음과 같은 경우 이메일은 도메인 소유자가 확인된 것으로 간주됩니다.

  1. 도메인은 사용자 계정이 있는 테넌트에 속하며 테넌트 관리자가 도메인 확인을 완료했습니다.
  2. 이메일이 MSA(Microsoft 계정)에서 전송되었습니다.
  3. 이메일이 Google 계정에서 온 것입니다.
  4. 이메일이 OTP(일회용 암호) 흐름을 사용한 인증에 사용되었습니다.

또한 Facebook 및 SAML/WS-Fed 계정에는 확인된 도메인이 없다는 점에 유의해야 합니다.

2023년 5월

Power BI 관리자 역할의 이름이 패브릭 관리자로 변경됩니다.

적용 날짜: 2023년 6월.

영향을 받는 엔드포인트:

  • 역할 정의 나열 - Microsoft Graph v1.0
  • 디렉터리 역할 목록 - Microsoft Graph v1.0

변경

Power BI 관리자 역할의 이름이 패브릭 관리자로 변경됩니다.

2023년 5월 23일, Microsoft는 Power BI를 통해 Data Factory 기반 데이터 통합 환경, Synapse 기반 데이터 엔지니어링, 데이터 웨어하우스, 데이터 과학, 실시간 분석 환경 및 BI(비즈니스 인텔리전스)를 제공하는 Microsoft Fabric을 공개했습니다(모두 레이크 중심 SaaS 솔루션에서 호스트됨). 이러한 환경에 대한 테넌트 및 용량 관리는 패브릭 관리 포털(이전에는 Power BI 관리 포털이라고 함)에 중앙 집중화되어 있습니다.

2023년 6월부터 Power BI 관리자 역할의 이름이 이 역할의 범위와 책임 변화에 맞춰 패브릭 관리자로 변경됩니다. Microsoft Entra ID, Microsoft Graph API, Microsoft 365 및 GDAP를 포함한 모든 애플리케이션은 몇 주 동안 새 역할 이름을 반영하기 시작합니다.

참고로, 애플리케이션 코드와 스크립트는 역할 이름이나 표시 이름을 기반으로 결정을 내려서는 안 됩니다.

2021년 12월

AD FS 사용자는 올바른 사용자가 로그인되어 있는지 확인하기 위해 더 많은 로그인 프롬프트를 보게 됩니다.

적용 날짜: 2021년 12월

영향을 받는 엔드포인트: Windows 통합 인증

영향을 받는 프로토콜: Windows 통합 인증

변경

오늘날 사용자가 인증을 위해 AD FS로 보내지면 사용자는 이미 AD FS 세션이 있는 모든 계정에 자동으로 로그인됩니다. 이 자동 로그인은 사용자가 다른 사용자 계정에 로그인하려는 경우에도 발생합니다. 이 잘못된 로그인이 발생하는 빈도를 줄이기 위해 Windows의 웹 계정 관리자가 로그인 중에 Microsoft Entra ID를 제공하는 경우 12월부터 Microsoft Entra ID login_hint 가 AD FS로 매개 변수를 보냅니 prompt=login 다. 이는 특정 사용자가 로그인을 원하는지 나타냅니다.

위의 요구 사항이 충족되면(로그인하기 위해 사용자를 Microsoft Entra ID로 보내는 데 WAM이 사용되며, login_hint AD FS 인스턴스가 포함되고기본 사용자가 지원하는 prompt=login경우) 사용자는 자동으로 로그인되지 않고 대신 AD FS에 계속 로그인할 사용자 이름을 제공하도록 요청합니다. 기존 ADFS 세션에 로그인하려는 경우 로그인 프롬프트 아래에 표시된 "현재 사용자로 계속" 옵션을 선택할 수 있습니다. 그렇지 않으면 로그인하려는 사용자 이름으로 계속할 수 있습니다.

이 변경 내용은 몇 주에 걸쳐 2021년 12월에 적용됩니다. 다음에 대한 로그인 동작은 변경하지 않습니다.

  • IWA를 직접 사용하는 애플리케이션
  • OAuth를 사용하는 애플리케이션
  • AD FS 인스턴스에 페더레이션되지 않은 도메인

2021년 10월

대화형 인증 중에 interaction_required를 반환하지 않는 오류 50105가 수정되었습니다.

적용 날짜: 2021년 10월

영향을 받는 엔드포인트: v2.0 및 v1.0

영향을 받은 프로토콜: 사용자 할당이 필요한 앱의 모든 사용자 흐름

변경

오류 50105(현재 할당)는 할당되지 않은 사용자가 관리자가 사용자 할당이 필요한 것으로 표시한 앱에 로그인을 시도할 때 발생합니다. 이것은 일반적인 액세스 제어 패턴이며 사용자는 종종 액세스 차단을 해제하기 위해 할당을 요청하는 관리자를 찾아야 합니다. 오류에는 interaction_required 오류 응답을 올바르게 처리하는 잘 코딩된 애플리케이션에서 무한 루프를 일으키는 버그가 있었습니다. interaction_required 는 앱에 대화형 인증을 수행하도록 지시하지만, 이렇게 한 후에도 Microsoft Entra ID는 여전히 오류 응답을 반환합니다 interaction_required .

오류 시나리오가 업데이트되어 비대화형 인증(여기서 prompt=none은 UX를 숨기는 데 사용됨) 동안 interaction_required 오류 응답을 사용하여 대화형 인증을 수행하도록 앱에 지시합니다. 후속 대화형 인증에서 Microsoft Entra ID는 이제 사용자를 유지하고 오류 메시지를 직접 표시하여 루프가 발생하지 않도록 합니다.

참고로 애플리케이션 코드는 AADSTS50105와 같은 오류 코드 문자열을 기반으로 결정해서는 안 됩니다. 대신 오류 처리 지침을 따르고 응답의 표준 error 필드에 있는 interaction_required 및 login_required와 같은 표준화된 인증 응답을 사용합니다. 다른 응답 필드는 문제를 해결하는 사람만 사용할 수 있습니다.

오류 조회 서비스에서 50105 오류의 현재 텍스트와 자세한 내용을 검토할 수 있습니다. https://login.microsoftonline.com/error?code=50105

단일 테넌트 애플리케이션의 AppId URI는 기본 체계 또는 확인된 도메인을 사용해야 합니다.

적용 날짜: 2021년 10월

영향을 받는 엔드포인트: v2.0 및 v1.0

영향을 받는 프로토콜: 모든 흐름

변경

단일 테넌트 애플리케이션의 경우 AppId URI를 추가하거나 업데이트하면 HTTPS 스키마 URI의 do기본 외부 테넌트에서 확인된 do기본 목록에 나열되거나 값이 Microsoft Entra ID에서 제공하는 기본 체계(api://{appId})를 사용하는지 확인합니다. 이렇게 하면 도메인이 확인된 도메인 목록에 없거나 값이 기본 체계를 사용하지 않는 경우 애플리케이션에서 AppId URI를 추가하지 못할 수 있습니다. 확인된 도메인에 대한 자세한 내용은 사용자 지정 도메인 문서를 참조하세요.

변경 사항은 AppID URI에서 확인되지 않은 도메인을 사용하는 기존 애플리케이션에 영향을 미치지 않습니다. 새 애플리케이션의 유효성을 검사하거나 기존 애플리케이션이 식별자 URI를 업데이트하거나 새 애플리케이션을 identifierUri 컬렉션에 추가할 때만 유효성을 검사합니다. 새로운 제한 사항은 2021년 10월 15일 이후에 앱의 identifierUris 컬렉션에 추가된 URI에만 적용됩니다. 2021년 10월 15일에 제한이 적용될 때 이미 애플리케이션의 identifierUris 컬렉션에 있는 AppId URI는 해당 컬렉션에 새 URI를 추가하더라도 계속 작동합니다.

요청이 유효성 검사에 실패하면 만들기/업데이트에 대한 애플리케이션 API는 HostNameNotOnVerifiedDomain을 나타내는 400 badrequest를 클라이언트에 반환합니다.

다음 API 및 HTTP 체계 기반 애플리케이션 ID URI 형식이 지원됩니다. 표 다음 목록에 설명된 대로 자리 표시자 값을 바꿉니다.

지원되는 애플리케이션 ID
URI 형식		 앱 ID URI의 예
api://<appId> api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<appId> api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<string> api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api
api://<string>/<appId> api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
https://<tenantInitialDomain>.onmicrosoft.com/<string> https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string> https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain> https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
  • <appId> - 애플리케이션 개체의 애플리케이션 ID(appId) 속성입니다.
  • <string> - 호스트 또는 API 패스 세그먼트의 문자열 값입니다.
  • <tenantId> - Azure 내에서 테넌트를 나타내기 위해 Azure에서 생성한 GUID입니다.
  • <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, 여기서 <tenantInitialDomain>은 초기 도메인 이름 및 테넌트 만들기 시 지정한 테넌트 작성자입니다.
  • <verifiedCustomDomain> - Microsoft Entra 테넌트용으로 구성된 확인된 사용자 지정 도메인입니다.

참고 항목

api:// 체계를 사용하는 경우 "api://" 바로 뒤에 문자열 값을 추가합니다. 예를 들면 api://<string>입니다. 해당 문자열 값은 GUID 또는 임의의 문자열일 수 있습니다. GUID 값을 추가하는 경우 앱 ID 또는 테넌트 ID와 일치해야 합니다. 애플리케이션 ID URI 값은 테넌트에서 고유해야 합니다. api://<tenantId>를 애플리케이션 ID URI로 추가하는 경우 다른 어떤 앱에서도 해당 URI를 사용할 수 없습니다. 대신 api://<appId> 또는 HTTP 체계를 사용하는 것이 좋습니다.

Important

애플리케이션 ID URI 값은 슬래시 "/" 문자로 끝나서는 안 됩니다.

참고 항목

현재 테넌트 내에서 앱 등록에 대한 identifierUris를 제거하는 것이 안전하지만 identifierUris를 제거하면 클라이언트가 다른 앱 등록에 실패할 수 있습니다.

2021년 8월

조건부 액세스는 명시적으로 요청된 범위에 대해서만 트리거됩니다.

적용 날짜: 2021년 8월, 4월부터 점진적으로 출시됩니다.

영향을 받는 엔드포인트: v2.0

영향을 받는 프로토콜: 동적 동의를 사용하는 모든 흐름

현재 동적 동의를 사용하는 애플리케이션은 scope 매개 변수에서 이름으로 요청되지 않은 경우에도 동의한 모든 권한을 부여합니다. 예를 들어 user.read만 요청하지만 files.read에 동의한 앱은 files.read에 대해 할당된 조건부 액세스 요구 사항을 통과하도록 강제할 수 있습니다.

불필요한 조건부 액세스 프롬프트 수를 줄이기 위해 Microsoft Entra ID는 명시적으로 요청된 범위만 조건부 액세스를 트리거하도록 범위를 애플리케이션에 제공하는 방식을 변경하고 있습니다. 요청 여부에 관계없이 토큰에 모든 범위를 포함하는 Microsoft Entra ID의 이전 동작을 사용하는 애플리케이션은 누락된 범위로 인해 중단 될 수 있습니다.

이제 앱은 요청된 토큰 및 조건부 액세스 프롬프트가 필요하지 않은 동의가 있는 권한이 혼합된 액세스 토큰을 받습니다. 토큰에 대한 액세스 범위는 토큰 응답의 scope 매개 변수에 반영됩니다.

이 동작에 대한 종속성이 관찰된 앱을 제외한 모든 앱에 대해 변경 내용이 적용됩니다. 개발자는 추가 조건부 액세스 프롬프트에 대한 종속성이 있을 수 있으므로 이러한 변경에서 제외되는 경우 지원을 받게 됩니다.

예제

앱이 user.read, files.readwrite 및 tasks.read에 동의했습니다. files.readwrite에는 조건부 액세스 정책이 적용되며 다른 두 경우에는 적용되지 않습니다. 앱이 scope=user.read에 대한 토큰 요청을 하고 현재 로그인한 사용자가 조건부 액세스 정책을 통과하지 않은 경우 결과 토큰은 user.read 및 tasks.read 권한에 대한 것입니다. 앱에 동의가 있기 때문에 tasks.read가 포함되며 조건부 액세스 정책을 적용할 필요가 없습니다.

그런 다음 앱이 scope=files.readwrite를 요청하면 테넌트에 필요한 조건부 액세스가 트리거되어 앱이 조건부 액세스 정책을 충족할 수 있는 대화형 인증 프롬프트를 표시하도록 합니다. 반환된 토큰에는 세 개의 범위가 모두 포함됩니다.

앱이 세 가지 범위(예 scope=tasks.read: )에 대해 마지막 요청을 하는 경우 Microsoft Entra ID는 사용자가 이미 필요한 files.readwrite조건부 액세스 정책을 완료했음을 확인하고 세 가지 권한 모두로 토큰을 다시 발급합니다.

2021년 6월

이제 디바이스 코드 흐름 UX에 앱 확인 프롬프트가 포함됩니다.

적용 날짜: 2021년 6월.

영향을 받는 엔드포인트: v2.0 및 v1.0

영향을 받는 프로토콜: 디바이스 코드 흐름

피싱 공격을 방지하기 위해 이제 디바이스 코드 흐름에 사용자가 예상하는 앱에 로그인하는지 유효성을 검사하는 프롬프트가 포함됩니다.

표시되는 프롬프트는 다음과 같습니다.

'Azure CLI에 로그인하려고 하시나요?'라는 새 메시지가 표시됩니다.

2020년 5월

버그 수정: Microsoft Entra ID는 더 이상 상태 매개 변수를 두 번 URL로 인코딩하지 않습니다.

적용 날짜: 2021년 5월

영향을 받는 엔드포인트: v1.0 및 v2.0

영향을 받는 프로토콜: /authorize 엔드포인트를 방문하는 모든 흐름(암시적 흐름 및 인증 코드 흐름)

Microsoft Entra 권한 부여 응답에서 버그가 발견되고 수정되었습니다. /authorize인증 기간 동안 요청의 state 매개 변수가 응답에 포함되어 앱 상태를 보존하고 CSRF 공격을 방지합니다. Microsoft Entra ID가 매개 변수를 응답에 state 삽입하기 전에 URL로 잘못 인코딩하여 다시 한 번 인코딩했습니다. 이로 인해 애플리케이션에서 Microsoft Entra ID의 응답을 잘못 거부하게 됩니다.

Microsoft Entra ID는 더 이상 이 매개 변수를 두 번 인코딩하지 않아 앱이 결과를 올바르게 구문 분석할 수 있습니다. 이 변경은 모든 애플리케이션에 적용됩니다.

Azure Government 엔드포인트 변경

적용 날짜: 2020년 5월 5일(2020년 6월 종료)

영향을 받는 엔드포인트: 모두

영향을 받는 프로토콜: 모든 흐름

2018년 6월 1일, Azure Government의 공식 Microsoft Entra Authority가 변경되었습니다 https://login-us.microsoftonline.comhttps://login.microsoftonline.us. 이 변경 내용은 Azure Government Microsoft Entra ID도 서비스하는 Microsoft 365 GCC High 및 DoD에도 적용됩니다. 미국 정부 테넌트 내에서 애플리케이션을 소유하는 경우 .us 엔드포인트에서 사용자를 로그인하도록 애플리케이션을 업데이트해야 합니다.

2020년 5월 5일에 Microsoft Entra ID가 엔드포인트 변경 적용을 시작하여 정부 사용자가 퍼블릭 엔드포인트(microsoftonline.com)를 사용하여 미국 정부 테넌트에서 호스트되는 앱에 로그인하지 못하도록 차단합니다. 영향을 받는 앱에는 AADSTS900439 - USGClientNotSupportedOnPublicEndpoint 오류가 표시됩니다. 이 오류는 앱이 퍼블릭 클라우드 엔드포인트에서 미국 정부 사용자 로그인을 시도하고 있음을 나타냅니다. 앱이 퍼블릭 클라우드 테넌트에 있고 미국 정부 사용자를 지원하려는 경우 앱을 업데이트하여 명시적으로 지원해야 합니다. 이를 위해서는 미국 정부 클라우드에서 새 앱 등록을 만들어야 할 수 있습니다.

이 변경의 적용은 미국 정부 클라우드의 사용자가 애플리케이션에 로그인하는 빈도에 따른 점진적 롤아웃을 사용하여 수행됩니다. 미국 정부 사용자로 로그인하는 앱이 가장 먼저 적용되고 미국 정부 사용자가 자주 사용하는 앱은 마지막에 적용됩니다. 2020년 6월에 모든 앱에서 적용이 완료될 것으로 예상됩니다.

자세한 내용은 이 마이그레이션의 Azure Government 블로그 게시물을 참조하세요.

2020년 3월

사용자 암호는 256자로 제한됩니다.

적용 날짜: 2020년 3월 13일

영향을 받는 엔드포인트: 모두

영향을 받는 프로토콜: 모든 사용자 흐름

Microsoft Entra ID에 직접 로그인하는 암호가 256자보다 긴 사용자(AD FS와 같은 페더레이션된 IDP 아님)는 로그인하기 전에 암호를 변경하라는 메시지가 표시됩니다. 관리 사용자의 암호를 재설정하는 데 도움이 되는 요청을 받을 수 있습니다.

로그인 로그의 오류는 AADSTS 50052: InvalidPasswordExceedsMaxLength와 유사합니다.

메시지: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

수정:

암호가 최대 허용 길이를 초과하기 때문에 사용자가 로그인할 수 없습니다. 암호를 다시 설정하려면 관리자에게 문의해야 합니다. SSPR이 테넌트에 사용하도록 설정된 경우 "암호 잊음" 링크에서 암호를 다시 설정할 수 있습니다.

2020년 2월

로그인 엔드포인트의 모든 HTTP 리디렉션에 빈 조각이 추가됩니다.

적용 날짜: 2020년 2월 8일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: response_type=query를 사용하는 OAuth 및 OIDC 흐름 - 경우에 따라 인증 코드 흐름 및 암시적 흐름이 포함됩니다.

HTTP 리디렉션을 통해 login.microsoftonline.com에서 애플리케이션으로 인증 응답을 보내면 서비스는 응답 URL에 빈 조각을 추가합니다. 이 작업을 수행하면 브라우저가 인증 요청에서 기존 조각을 모두 삭제하도록 하여 리디렉션 공격의 클래스를 방지합니다. 이 동작에 대한 종속성이 있는 앱이 없습니다.

2019년 8월

POST 양식 의미 체계가 더 엄격하게 적용됩니다. 공백과 따옴표는 무시됩니다.

적용 날짜: 2019년 9월 2일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: POST가 사용되는 모든 곳(클라이언트 자격 증명, 인증 코드 상환, ROPC, OBO 및 새로 고침 토큰 상환)

2019년 9월 2일부터 POST 방법을 사용하는 인증 요청은 더 엄격한 HTTP 표준을 사용하여 검증됩니다. 특히 공백과 큰따옴표(")는 더 이상 요청 양식 값에서 제거되지 않습니다. 이러한 변경은 기존 클라이언트를 중단하지 않을 것으로 예상되며, Microsoft Entra ID로 전송된 요청이 매번 안정적으로 처리되도록 합니다. Microsoft는 앞으로(위 참조) 중복 매개 변수를 추가로 거부하고 요청 내에서 BOM을 무시할 예정입니다.

예시:

현재 ?e= "f"&g=h는 ?e=f&g=h(즉, e == f)와 동일하게 구문 분석됩니다. 이 변경을 통해 이를 구문 분석하므로 e == "f"는 유효한 인수가 될 가능성이 낮고 요청이 실패합니다.

2019년 7월

단일 테넌트 애플리케이션에 대한 앱 전용 토큰은 클라이언트 앱이 리소스 테넌트에 있는 경우에만 발급됩니다.

적용 날짜: 2019년 7월 26일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: 클라이언트 자격 증명(앱 전용 토큰)

클라이언트 자격 증명 부여를 통해 앱 전용 토큰이 발급되는 방식을 변경하는 보안 변경 사항이 2019년 7월 26일에 적용되었습니다. 이전에는 애플리케이션이 테넌트의 존재 여부 또는 해당 애플리케이션에 대해 동의한 역할에 관계없이 다른 앱을 호출하기 위한 토큰을 받을 수 있었습니다. 이 동작은 리소스(웹 API라고도 함)가 단일 테넌트(기본값)로 설정되도록 업데이트되었으므로 클라이언트 애플리케이션이 리소스 테넌트 내에 있어야 합니다. 클라이언트와 API 간의 기존 동의는 여전히 필요하지 않으며 앱은 roles 클레임이 있고 API에 대한 예상 값을 포함하는지 확인하기 위해 계속해서 자체 권한 부여 검사를 수행해야 합니다.

이 시나리오에 대한 오류 메시지는 현재 다음과 같습니다.

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

이 문제를 해결하려면 관리자 동의 환경을 사용하여 테넌트에서 클라이언트 애플리케이션 서비스 주체를 만들거나 수동으로 만듭니다. 이 요구 사항은 테넌트가 테넌트 내에서 작동할 수 있는 애플리케이션 권한을 부여했는지 확인합니다.

예제 요청

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... 이 예에서 리소스 테넌트(권한)는 contoso.com이고 리소스 앱은 Contoso 테넌트에 대한 gateway.contoso.com/api라는 단일 테넌트 앱이며 클라이언트 앱은 00001111-aaaa-2222-bbbb-3333cccc4444입니다. 클라이언트 앱이 Contoso.com 내에 서비스 주체를 포함하는 경우 이 요청을 계속할 수 있습니다. 그러나 포함하지 않는 경우에는 위의 오류가 발생하여 요청이 실패합니다.

그러나 Contoso 게이트웨이 앱이 다중 테넌트 애플리케이션인 경우 Contoso.com 내에 서비스 주체가 있는 클라이언트 앱에 관계없이 요청이 계속됩니다.

이제 리디렉션 URI는 쿼리 문자열 매개 변수를 포함할 수 있습니다.

적용 날짜: 2019년 7월 22일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: 모든 흐름

RFC 6749에 따라 Microsoft Entra 애플리케이션은 이제 OAuth 2.0 요청에 대해 정적 쿼리 매개 변수(예: https://contoso.com/oauth2?idp=microsoft)를 사용하여 리디렉션(회신) URI를 등록하고 사용할 수 있습니다. 동적 리디렉션 URI는 보안 위험을 나타내므로 사용할 수 없으며 인증 요청에 대한 상태 정보를 유지하는 데 사용할 수 없습니다. 즉, state 매개 변수를 사용합니다.

정적 쿼리 매개 변수는 리디렉션 URI의 다른 부분과 마찬가지로 리디렉션 URI에 대한 일치 문자열을 따릅니다. URI가 디코딩된 redirect_uri와 일치하는 문자열이 등록되지 않은 경우에는 요청이 거부됩니다. 앱 등록에서 URI가 발견되면 정적 쿼리 매개 변수를 포함하여 전체 문자열이 사용자를 리디렉션하는 데 사용됩니다.

현재(2019년 7월 말) Azure Portal의 앱 등록 UX는 여전히 쿼리 매개 변수를 차단합니다. 그러나 애플리케이션 매니페스트를 수동으로 편집하여 쿼리 매개 변수를 추가하고 앱에서 이를 테스트할 수 있습니다.

2019년 3월

반복 클라이언트가 중단됩니다.

적용 날짜: 2019년 3월 25일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: 모든 흐름

클라이언트 애플리케이션은 경우에 따라 잘못 작동하여 짧은 시간 동안 수백 개의 동일한 로그인 요청을 발행할 수 있습니다. 이러한 요청은 성공할 수도 있고 성공하지 못할 수도 있지만 모두 사용자 환경의 성능을 저하시키고 IDP의 워크로드를 늘리므로 사용자의 대기 시간이 증가하고 IDP의 가용성이 떨어집니다. 이러한 애플리케이션은 정상적인 사용 범위를 벗어나 작동되며, 올바르게 동작하도록 업데이트되어야 합니다.

중복 요청을 여러 번 발행하는 클라이언트에는 invalid_grant 오류: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request가 전송됩니다.

대부분의 클라이언트는 이 오류를 피하기 위해 동작을 변경할 필요가 없습니다. 잘못 구성된 클라이언트(토큰 캐싱이 없거나 이미 프롬프트 루프가 있는 클라이언트)만 이 오류의 영향을 받습니다. 클라이언트는 다음 요소에 대해 로컬(쿠키를 통해) 인스턴스별로 추적됩니다.

  • 사용자 힌트(있는 경우)

  • 요청되는 범위 또는 리소스

  • Client ID

  • 리디렉션 URI

  • 응답 유형 및 모드

짧은 시간(5분)에 여러 요청(15개 이상)을 하는 앱에는 반복되고 있음을 설명하는 invalid_grant 오류가 수신됩니다. 요청되는 토큰의 수명은 충분히 길기 때문에(최소 10분, 기본적으로 60분) 이 기간 동안 반복되는 요청은 필요하지 않습니다.

모든 앱은 토큰을 자동으로 요청하는 대신 대화형 프롬프트를 표시하여 invalid_grant를 처리해야 합니다. 클라이언트는 이 오류를 방지하기 위해 수신하는 토큰을 올바르게 캐싱하는지 확인해야 합니다.

2018년 10월

권한 부여 코드는 더 이상 재사용할 수 없습니다.

개시 날짜: 2018년 11월 15일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: 코드 흐름

2018년 11월 15일부터 Microsoft Entra ID는 앱에 대해 이전에 사용한 인증 코드 수락을 중지합니다. 이 보안 변경은 OAuth 사양에 따라 Microsoft Entra ID를 가져오는 데 도움이 되며 v1 및 v2 엔드포인트 모두에 적용됩니다.

앱에서 여러 리소스에 대한 토큰을 얻기 위해 인증 코드를 재사용하는 경우에는 코드를 사용하여 새로 고침 토큰을 얻은 다음, 이 새로 고침 토큰을 사용하여 다른 리소스에 대한 추가 토큰을 얻는 것이 좋습니다. 인증 코드는 한 번만 사용할 수 있지만 새로 고침 토큰은 여러 리소스에서 여러 번 사용할 수 있습니다. OAuth 코드 흐름 중에 인증 코드를 다시 사용하려고 하는 새 앱에서는 invalid_grant 오류가 발생합니다.

새로 고침 토큰에 대한 자세한 내용은 액세스 토큰 새로 고침을 참조하세요. ADAL 또는 MSAL을 사용하는 경우 이 작업은 라이브러리를 통해 처리됩니다. AcquireTokenByAuthorizationCodeAsync의 두 번째 인스턴스를 AcquireTokenSilentAsync로 바꿉니다.

2018년 5월

ID 토큰은 OBO 흐름에 사용할 수 없습니다.

날짜: 2018년 5월 1일

영향을 받는 엔드포인트: v1.0 및 v2.0 모두

영향을 받는 프로토콜: 암시적 흐름 및 On-Behalf-Of 흐름

2018년 5월 1일 이 OBO 흐름에서 새 애플리케이션의 어설션으로 id_token을 사용할 수 없습니다. API를 보호하려면 클라이언트와 동일한 애플리케이션의 중간 계층 사이에서도 액세스 토큰을 대신 사용해야 합니다. 2018년 5월 1일 전에 등록된 앱은 계속 작동하고 id_token을 액세스 토큰으로 교환할 수 있지만 이 패턴은 모범 사례로 간주되지 않습니다.

이 변경 문제를 해결하려면 다음을 수행할 수 있습니다.

  1. 하나 이상의 범위가 있는 애플리케이션의 웹 API를 만듭니다. 이 명시적 진입점으로 인해 더 세분화된 제어 및 보안이 가능합니다.
  2. 앱 매니페스트, Azure Portal 또는 앱 등록 포털에서 앱이 암시적 흐름을 통해 액세스 토큰을 발급할 수 있는지 확인합니다. 이 작업은 oauth2AllowImplicitFlow 키를 통해 제어됩니다.
  3. 클라이언트 애플리케이션에서 response_type=id_token을 통해 id_token을 요청할 때 위에서 만든 웹 API의 액세스 토큰(response_type=token)도 요청합니다. 따라서 v2.0 엔드포인트를 사용하는 경우 scope 매개 변수는 api://GUID/SCOPE와 비슷하게 표시되어야 합니다. V1.0 엔드포인트에서 resource 매개 변수는 Web API의 앱 URI여야 합니다.
  4. Id_token 대신 중간 계층으로 이 액세스 토큰을 전달합니다.