위임된 액세스 이해
사용자가 앱에 로그인하여 이러한 앱을 사용하여 Microsoft Graph와 같은 다른 리소스에 액세스하는 경우 앱은 먼저 사용자를 대신하여 이 리소스에 액세스할 수 있는 권한을 요청해야 합니다. 이러한 일반적인 시나리오를 위임된 액세스라고 합니다.
위임된 액세스를 사용해야 하는 이유는 무엇인가요?
사람들은 다른 애플리케이션을 사용하여 클라우드 서비스에서 데이터에 액세스하는 경우가 자주 있습니다. 예를 들어 즐겨 찾는 PDF 판독기 애플리케이션을 사용하여 OneDrive에 저장된 파일을 보려고 할 수 있습니다. 또 다른 예로는 동료에 대한 공유 정보를 검색하여 요청에 대한 검토자를 쉽게 선택할 수 있도록 하는 회사의 기간 업무 애플리케이션이 있습니다. 이러한 경우 클라이언트 애플리케이션, PDF 판독기 또는 회사의 요청 승인 도구는 애플리케이션에 로그인한 사용자를 대신하여 이 데이터에 액세스할 수 있는 권한을 받아야 합니다.
로그인한 사용자가 자체 리소스 또는 액세스할 수 있는 리소스로 작업하도록 하려는 경우 위임된 액세스를 사용합니다. 전체 조직에 대한 정책을 설정하는 관리자이든, 받은 편지함에서 메일을 삭제하는 사용자이든, 사용자 작업과 관련된 모든 시나리오는 위임된 액세스를 사용해야 합니다.
반면 일반적으로 자동화와 같이 로그인한 사용자 없이 실행해야 하는 시나리오에서 위임된 액세스가 적절하지 않습니다. 또한 데이터 손실 방지 또는 백업 등, 많은 사용자의 리소스에 액세스하는 시나리오에서도 적절하지 않을 수 있습니다. 이러한 유형의 작업에는 애플리케이션 전용 액세스를 사용하는 것이 좋습니다.
클라이언트 앱으로 범위 요청
앱은 액세스하려는 리소스 앱에 대해 특정 범위 또는 범위 집합을 허가하도록 사용자에게 요청해야 합니다. 범위를 위임된 권한이라고도 합니다. 이러한 범위는 리소스 및 앱이 사용자를 대신하여 수행하려는 작업을 설명합니다. 예를 들어 앱에서 최근에 받은 메일 메시지 및 채팅 메시지 목록을 사용자에게 표시하려는 경우 사용자에게 Microsoft Graph Mail.Read 및 Chat.Read 범위에 동의하도록 요청할 수 있습니다.
앱이 범위를 요청하면 사용자 또는 관리자가 요청된 액세스에 대해 권한을 부여해야 합니다. Outlook.com 또는 Xbox Live 계정과 같은 Microsoft 계정을 사용하는 소비자는 항상 자체적으로 범위를 허가할 수 있습니다. Microsoft Entra 계정이 있는 조직 사용자는 조직의 설정에 따라 범위를 허가할 수도 있거나 허가하지 못할 수도 있습니다. 조직 사용자가 범위에 직접 동의할 수 없는 경우 조직의 관리자에게 동의하도록 요청해야 합니다.
항상 최소 권한 원칙을 따릅니다. 즉, 앱에 필요하지 않은 범위를 요청해서는 안 됩니다. 이 원칙은 앱이 손상된 경우 보안 위험을 제한하고 관리자가 앱 액세스 권한을 더 쉽게 부여할 수 있도록 합니다. 예를 들어 앱은 사용자가 속한 채팅만 나열해야 하지만 채팅 메시지를 직접 표시할 필요가 없는 경우 Chat.Read 대신 더 제한된 Microsoft Graph Chat.ReadBasic 범위를 요청해야 합니다. openID 범위에 대한 자세한 내용은 OpenID 범위를 참조하세요.
리소스 서비스에 대한 범위 디자인 및 게시
API를 빌드하고 사용자를 대신하여 위임된 액세스를 허용하려면 다른 앱에서 요청할 수 있는 범위를 만들어야 합니다. 이러한 범위는 클라이언트에서 사용할 수 있는 작업 또는 리소스를 설명해야 합니다. 범위를 디자인할 때는 개발자 시나리오를 고려해야 합니다.
자체 토큰
시나리오에서 다음을 수행합니다.
- 리소스 애플리케이션과 클라이언트 애플리케이션은 동일합니다.
- 애플리케이션에 등록된 웹 API가 없습니다.
- 애플리케이션이 자신을 노출하는 위임된 권한에 대한 토큰을 요청하고 있습니다.
이 토큰 요청에 대한 동의가 필요하거나 표시되지 않습니다. 또한 테넌트 내에서 만들어지고 자신에게 토큰을 요청하는 앱은 이미 프로필 데이터에 대한 액세스 권한을 갖도록 유추할 수 있으며 프로필 액세스 권한이 자동으로 부여됩니다.
위임된 액세스는 어떻게 작동하나요?
위임된 액세스에 대해 기억해야 할 가장 중요한 점은 클라이언트 앱과 로그인한 사용자 모두에 적절한 권한을 부여해야 한다는 것입니다. 범위를 허가하는 것만으로는 충분하지 않습니다. 클라이언트 앱에 올바른 범위가 없거나 사용자에게 리소스를 읽거나 수정할 수 있는 충분한 권한이 없는 경우 호출이 실패합니다.
- 클라이언트 앱 권한 부여 - 클라이언트 앱은 범위를 허가하여 권한을 부여합니다. 일부 리소스에 액세스하기 위해 사용자 또는 관리자가 클라이언트 앱에 범위를 허가하면 해당 권한 부여가 Microsoft Entra ID에 기록됩니다. 클라이언트가 관련 사용자를 대신하여 리소스에 액세스하도록 요청한 모든 위임된 액세스 토큰은
scp클레임에 해당 범위의 클레임 값을 포함합니다. 리소스 앱은 이 클레임을 확인하여 클라이언트 앱에 호출에 대한 올바른 범위가 허가되었는지 여부를 확인합니다. - 사용자 권한 부여 - 호출하는 리소스에 의해 사용자에게 권한이 부여됩니다. 리소스 앱은 역할 기반 액세스 제어, 소유권/멤버 자격 관계, 액세스 제어 목록 또는 기타 검사와 같은 하나 이상의 시스템을 사용자 권한 부여에 사용할 수 있습니다. 예를 들어 Microsoft Entra ID는 사용자가 조직의 애플리케이션을 삭제하도록 허용하기 전에 앱 관리 또는 일반 관리자 역할에 할당되었는지 확인하지만, 모든 사용자가 소유한 애플리케이션을 삭제하도록 허용합니다. 마찬가지로 SharePoint Online 서비스는 사용자가 파일을 열 수 있도록 허용하기 전에 파일에 대한 적절한 소유자 또는 읽기 권한자 권한이 있는지 확인합니다.
위임된 액세스 예제 – Microsoft Graph를 통한 OneDrive
다음 예제를 참조하세요.
Alice는 클라이언트 앱을 사용하여 리소스 API인 Microsoft Graph로 보호되는 파일을 열려고 합니다. 사용자 권한 부여를 위해 OneDrive 서비스는 파일이 Alice의 드라이브에 저장되어 있는지 여부를 확인합니다. 다른 사용자의 드라이브에 저장된 경우 Alice는 다른 사용자의 드라이브를 읽을 권리가 없으므로 OneDrive는 Alice의 요청을 승인되지 않은 것으로 거부합니다.
클라이언트 앱 권한 부여의 경우 OneDrive는 호출을 하는 클라이언트에 로그인한 사용자를 대신하여 Files.Read 범위를 사용하도록 허가되었는지 여부를 확인합니다. 이 경우 로그인한 사용자는 Alice입니다. Alice를 대신해서 앱에 Files.Read가 허가되지 않은 경우 OneDrive도 요청을 처리하지 못합니다.
| GET /drives/{id}/files/{id} | Alice를 대신해서 클라이언트 앱에 Files.Read 범위가 허가됨 |
Alice를 대신해서 클라이언트 앱에 Files.Read 범위가 허가되지 않음 |
|---|---|---|
| 이 문서는 Alice의 OneDrive에 있습니다. | 200 – 액세스 권한 부여됨 | 403 - 권한 없음 Alice(또는 관리자)는 이 클라이언트가 파일을 읽도록 허용하지 않았습니다. |
| 이 문서는 다른 사용자의 OneDrive*에 있습니다. | 403 - 권한 없음 Alice는 이 파일을 읽을 권한이 없습니다. 클라이언트에 Files.Read가 허가되었지만 Alice를 대신하여 작업할 경우에는 거부됩니다. |
403 – 권한 없음 Alice는 이 파일을 읽을 권한이 없으며 클라이언트는 Alice에게 액세스 권한이 있는 파일을 읽을 수 없습니다. |
제공된 예제는 위임된 권한 부여를 보여 줍니다. 프로덕션 OneDrive 서비스는 공유 파일 등의 여러 다른 액세스 시나리오를 지원합니다.