Criar aplicativos incorporados do SharePoint

Os desenvolvedores podem criar aplicativos que utilizam os poderosos recursos de gerenciamento de arquivos e documentos no SharePoint por meio do SharePoint Embedded. Esses tipos de aplicativos têm dois componentes distintos.

• Um componente é responsável por executar operações CRUD no SharePoint Embedded usando APIs do Microsoft Graph.
• O outro componente implementa a interface para que os usuários consumam e armazenem os documentos armazenados no SharePoint Embedded.

Apresentando o SharePoint Embedded

O SharePoint Embedded fornece uma maneira mais rápida para os desenvolvedores criarem aplicativos focados em arquivos e documentos. O SharePoint Embedded é da plataforma SharePoint. Os desenvolvedores podem integrar os mesmos recursos avançados de arquivos e documentos que o SharePoint tem a oferecer em seus próprios aplicativos personalizados.

Outra maneira de ver o SharePoint Embedded é que seu aplicativo personalizado usa o SharePoint para todos os recursos de colaboração e armazenamento de documentos. Isso usa efetivamente o SharePoint Embedded como uma "API sem periféricos" para o sistema de armazenamento de documentos do SharePoint.

Os documentos do aplicativo permanecem em seu locatário do Microsoft 365

Quando um consumidor instala/registra um aplicativo do SharePoint Embedded em seu locatário do Microsoft 365, o SharePoint Embedded cria outra partição do SharePoint. Essa partição de armazenamento não tem uma interface de usuário, mas, em vez disso, os documentos na partição só podem ser acessados por meio de APIs. Isso significa que todos os documentos estarão acessíveis ao ISV ou ao aplicativo do desenvolvedor, mas os documentos residirão apenas no locatário do Microsoft 365 do consumidor.

As configurações do Microsoft 365 do consumidor se aplicam a documentos de aplicativo

Todos os documentos armazenados na partição do SharePoint criada pelo aplicativo incorporado do SharePoint estão no locatário do consumidor do Microsoft 365 e, portanto, estão sujeitos às configurações de locatário do consumidor do Microsoft 365.

Noções básicas sobre diferentes tipos, permissões de aplicativos e o fluxo Em Nome de

Ao criar aplicativos para essas APIs REST de acesso, como Microsoft Graph e SharePoint Online, diferentes tarefas exigem diferentes tipos de acesso. Para resolver isso, o OAuth v2.0 é um padrão aberto para autorização usado para acesso à API, incluindo Microsoft Graph e SharePoint Online. Ele fornece aos aplicativos acesso delegado a recursos protegidos em nome de um usuário. Isso inclui dois tipos de permissões: Aplicativo+Usuário (também conhecido como Delegado) e Somente Aplicativo (ou Aplicativo).

• Permissões de Aplicativo+Usuário (ou Delegadas): trata-se de um modelo de permissão de duas partes. O aplicativo está executando tarefas e chamando APIs em nome de um usuário conectado. O aplicativo recebe permissões delegadas do usuário que faz login nele, herdando os privilégios que o usuário tem, incluindo quaisquer restrições, como não poder acessar determinados dados ou realizar determinadas ações. Isso reflete as tarefas que o usuário permitiu que o aplicativo realizasse em seu nome durante a sessão.

  Por exemplo, um aplicativo pode receber permissão para enviar um email em nome de um usuário, mas se o usuário não tiver permissão para enviar um email, o aplicativo também não poderá enviá-lo.

  Esse tipo de permissão geralmente é usado quando você deseja que seu aplicativo opere como o usuário conectado faria, em cenários de aplicativo em que a interação é em nome de um usuário e as permissões devem variar de acordo com o usuário que concede consentimento.

• Permissões somente de aplicativo (ou aplicativo): as permissões somente de aplicativo, por outro lado, são usadas quando um aplicativo precisa acessar recursos independentemente de um usuário. O aplicativo obtém as permissões concedidas diretamente a si mesmo, independentemente das permissões do usuário. Ele permite que o aplicativo acesse o serviço de API com sua própria identidade e privilégios. Isso é ideal para serviços em segundo plano ou daemons executados independentemente de uma sessão de usuário.

Por exemplo, se você tiver um aplicativo que precisa acessar todos os arquivos em uma biblioteca de documentos, mesmo aqueles que não são compartilhados com nenhum usuário, as permissões somente do aplicativo seriam a escolha certa.

As permissões de aplicativo só podem ser consentidas por um administrador porque, muitas vezes, concedem privilégios mais altos.

Além dessas duas opções, um terceiro fluxo OAuth 2.0, On-Behalf-Of (também conhecido como fluxo OBO ) pode ser usado quando um aplicativo precisa executar uma tarefa em nome do usuário. Veja como funciona todo o fluxo OBO:

1. Um aplicativo cliente é autenticado no servidor de autorização (como o Microsoft Entra ID) e solicita um token de acesso para uma API (como o servidor de API do nosso projeto).
2. O usuário entra e permite que o aplicativo aja em seu nome.
3. O aplicativo cliente recebe um token de acesso e um token de atualização que representa a sessão do usuário.
4. Quando o aplicativo cliente precisa chamar outro serviço, como o SharePoint Online, em nome do usuário, ele envia o token de acesso obtido anteriormente no Authorization cabeçalho HTTP.
5. Nossa API do lado do servidor valida o token de acesso e processa a solicitação. Se precisar chamar outro serviço (como o SharePoint Online) em nome do usuário, ele buscará um token do Microsoft Entra ID apresentando esse token já obtido.
6. O Microsoft Entra ID emite um "novo" token de acesso para o SharePoint Online que o servidor de API do nosso projeto agora pode usar para chamar o SharePoint Online.

Em um cenário prático que lida com o Microsoft Graph ou o SharePoint Online, quando um usuário deseja que um aplicativo acesse seu calendário, não é ideal que o aplicativo entre para cada operação individual. Em vez disso, com o fluxo OBO, o usuário só precisa se autenticar uma vez e o aplicativo executará todas as operações autorizadas em seu nome.

Assim, o fluxo OBO simplifica a experiência do usuário e aumenta a segurança do sistema, garantindo que as permissões sejam validadas sempre que uma cadeia de chamadas é feita.

Resumo

Nesta seção, você concluiu as etapas iniciais para criar um aplicativo Web que executará operações CRUD em um Contêiner do SharePoint Embedded.