인증의 새로운 기능?
Microsoft는 보안, 사용성 및 표준 준수를 개선하기 위해 Microsoft ID 플랫폼의 기능을 주기적으로 추가 및 수정합니다.
달리 명시되지 않는 한 여기에 설명된 변경 내용은 명시된 변경 발효일 이후에 등록된 애플리케이션에만 적용됩니다.
이 문서를 정기적으로 확인하여 다음에 대해 알아봅니다.
- 알려진 문제 및 수정 사항
- 프로토콜 변경 내용
- 더 이상 사용되지 않는 기능
팁
이 페이지에 대한 업데이트 알림을 받으려면 RSS 피드 판독기에 다음 URL을 추가합니다.https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us
2024년 8월
이제 페더레이션 ID 자격 증명에서 대/소문자 구분 일치 사용
유효 날짜: 2024년 9월
영향을 받은 프로토콜: 워크로드 ID 페더레이션
변경
이전에는 FIC(Federated Identity Credential) issuersubject및 해당 값과 audience 일치하는 issuersubject값 및 audience 외부 IdP가 Microsoft Entra ID로 보낸 토큰에 포함된 값을 일치시키는 경우 대/소문자를 구분하지 않는 일치가 사용되었습니다. 고객에게 보다 세분화된 제어를 제공하기 위해 대/소문자 구분 일치를 적용하는 것으로 전환하고 있습니다.
잘못된 예:
- 토큰 주체:
repo:contoso/contoso-org:ref:refs/heads/main - FIC 제목:
repo:Contoso/Contoso-Org:ref:refs/heads/main
이러한 두 주체 값은 대/소문자를 구분하지 않으므로 유효성 검사가 실패합니다. 동일한 메커니즘이 적용 issuer 되고 audience 유효성 검사가 수행됩니다.
이 변경 내용은 처음에 애플리케이션 또는 이후에 만든 August 14th, 2024관리 ID에 적용됩니다. 비활성 애플리케이션 또는 관리 ID는 대/소문자 구분 일치를 시작하는 September 27th, 2024데 필요한 기간 August 1st, 2024 August 31st, 2024사이에 해당 애플리케이션 또는 관리 ID에서 수행한 워크로드 ID 페더레이션 요청이 0으로 결정됩니다. 활성 애플리케이션의 경우 대/소문자를 구분하지 않는 일치는 나중에 전달될 예정입니다.
대/소문자를 구분하지 않아 오류를 더 잘 강조 표시하기 위해 오류 메시지를 수정하고 있습니다 AADSTS700213. 이제 상태가 됩니다.
`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.`
자리 표시자는 '{subject}' 외부 IdP에서 Microsoft Entra ID로 전송되는 토큰에 포함된 주체 클레임의 값을 제공합니다. 이 오류 템플릿은 주변 issuer 및 audience 유효성 검사와 관련된 대/소문자를 구분하지 않는 오류에도 사용됩니다. 이 오류가 발생하면 오류에 해당issuersubject하거나 audience 오류에 나열된 페더레이션 ID 자격 증명을 찾아 대/소문자를 구분하는 관점에서 해당 값이 동일한지 확인해야 합니다. 일치하지 않는 경우 FIC의 현재 issuer또는 audience subject값을 오류 메시지에 포함된 값 또는 audience 값으로 issuersubject바꿔야 합니다.
참고 항목
GitHub Actions를 사용하고 이 오류가 발생하는 Azure 앱 서비스 고객의 경우 이 문제를 해결하는 옵션은 GitHub 리포지토리의 워크플로 파일로 /.github/workflows 이동하여 환경 name 속성을 "Production" 업데이트하는 것입니다"production". 이 지침은 Azure 앱 서비스 시나리오에만 적용됩니다. 다른 시나리오에서 이 오류가 발생하는 경우 위의 지침을 참조하세요.
2024년 6월
애플리케이션은 디렉터리에 등록되어야 합니다.
적용 날짜: 2024년 6월
영향을 받는 엔드포인트: v2.0 및 v1.0
영향을 받는 프로토콜: 모든 흐름
변경
이전에는 Microsoft Entra 앱 등록 환경을 사용하여 애플리케이션을 등록할 때 사용자가 MSA(개인 Microsoft 계정)로 로그인한 경우 애플리케이션을 개인 계정 연결하도록 선택할 수 있었습니다. 즉, 애플리케이션이 디렉터리에 연결되거나 포함되지 않습니다('테넌트' 또는 '조직'이라고도 함). 그러나 2024년 6월부터 모든 애플리케이션은 디렉터리에 등록되어야 합니다. 기존 디렉터리이거나 개인 Microsoft 계정 사용자가 Microsoft Entra 애플리케이션 및 기타 Microsoft 리소스를 보관하기 위해 만든 새 디렉터리일 수 있습니다. 사용자는 Microsoft 365 개발자 프로그램에 가입하거나 Azure에 등록하여 이 용도로 사용할 새 디렉터리를 쉽게 만들 수 있습니다.
애플리케이션을 개인 계정 연결하기만 하는 대신 디렉터리에 등록하면 다양한 이점이 있습니다. 여기에는 다음이 포함됩니다.
- 디렉터리에 등록된 애플리케이션에는 앱에 둘 이상의 소유자를 추가하는 기능, 앱을 게시하는 기능 등 더 많은 기능을 사용할 수 있습니다.
- 애플리케이션은 개발자가 사용하는 다른 Microsoft 리소스(예: Azure 리소스)와 동일한 위치에 있습니다.
- 애플리케이션은 향상된 복원력 이점을 받습니다.
개인 계정 연결된 기존 애플리케이션을 포함하여 기존 애플리케이션에는 영향을 주지 않습니다. 새 애플리케이션을 등록하는 기능만 영향을 받습니다.
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 클레임이 요청되면 도메인 소유자가 확인되지 않은 이메일이 기본적으로 생략됩니다.
다음과 같은 경우 이메일은 도메인 소유자가 확인된 것으로 간주됩니다.
- 도메인은 사용자 계정이 있는 테넌트에 속하며 테넌트 관리자가 도메인 확인을 완료했습니다.
- 이메일이 MSA(Microsoft 계정)에서 전송되었습니다.
- 이메일이 Google 계정에서 온 것입니다.
- 이메일이 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 세션이 있는 모든 계정에 자동으로 로그인됩니다. 이 자동 로그인은 사용자가 다른 사용자 계정에 로그인하려는 경우에도 발생합니다. 이 잘못된 로그인이 발생하는 빈도를 줄이기 위해 12월부터 Microsoft Entra ID는 Windows의 웹 계정 관리자가 로그인하는 동안Microsoft Entra ID에 login_hint를 제공하는 경우 prompt=login 매개 변수를 ADFS로 보냅니다. 이는 특정 사용자가 로그인하기를 원하는지 나타냅니다.
위의 요구 사항이 충족되면(WAM은 사용자를 Microsoft Entra ID로 보내 로그인하는 데 사용되며, login_hint가 포함되고 사용자 도메인의 ADFS 인스턴스는 prompt=login을 지원함) 사용자는 자동으로 로그인하지 않고 대신 ADFS에 계속 로그인하려면 사용자 이름을 제공하라는 요청을 받습니다. 기존 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의 도메인이 고객 테넌트의 확인된 도메인 목록에 나열되어 있는지 또는 값이 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://00001111-aaaa-2222-bbbb-3333cccc4444 |
| api://<tenantId>/<appId> | api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444 |
| api://<tenantId>/<string> | api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api |
| api://<string>/<appId> | api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444 |
| 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
영향을 받는 프로토콜: 디바이스 코드 흐름
피싱 공격을 방지하기 위해 이제 디바이스 코드 흐름에 사용자가 예상하는 앱에 로그인하는지 유효성을 검사하는 프롬프트가 포함됩니다.
표시되는 프롬프트는 다음과 같습니다.
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 권한이 https://login-us.microsoftonline.com에서 https://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(AD FS와 같은 페더레이션된 IDP가 아님)에 직접 로그인하는 256자보다 긴 암호를 사용하는 사용자는 로그인하기 전에 암호를 변경하라는 메시지가 표시됩니다. 관리자는 사용자의 암호를 다시 설정하는 데 도움을 달라는 요청을 받을 수 있습니다.
로그인 로그의 오류는 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는 이전에 앱에 사용된 인증 코드를 더 이상 허용하지 않습니다. 이 보안 변경은 Microsoft Entra ID를 OAuth 사양에 맞추는 데 도움이 되며 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을 액세스 토큰으로 교환할 수 있지만 이 패턴은 모범 사례로 간주되지 않습니다.
이 변경 문제를 해결하려면 다음을 수행할 수 있습니다.
- 하나 이상의 범위가 있는 애플리케이션의 웹 API를 만듭니다. 이 명시적 진입점으로 인해 더 세분화된 제어 및 보안이 가능합니다.
- 앱 매니페스트, Azure Portal 또는 앱 등록 포털에서 앱이 암시적 흐름을 통해 액세스 토큰을 발급할 수 있는지 확인합니다. 이 작업은
oauth2AllowImplicitFlow키를 통해 제어됩니다. - 클라이언트 애플리케이션에서
response_type=id_token을 통해 id_token을 요청할 때 위에서 만든 웹 API의 액세스 토큰(response_type=token)도 요청합니다. 따라서 v2.0 엔드포인트를 사용하는 경우scope매개 변수는api://GUID/SCOPE와 비슷하게 표시되어야 합니다. V1.0 엔드포인트에서resource매개 변수는 Web API의 앱 URI여야 합니다. - Id_token 대신 중간 계층으로 이 액세스 토큰을 전달합니다.