Vous ne devez pas nécessairement mettre en œuvre le critère d'évaluation /wopibootstrapper ni la méthode GetNewAccessToken. Ils sont spécifiques au Office Online (365) integration program.
Votre travail consiste simplement à générer un access_token qui serait inclus dans une demande POST de la trame WOPI dans votre application (similaire à l'image de votre question).
Ce jeton sera utilisé par le client WOPI (WAC/OWA/OOS Server). Le client WOPI n'a pas besoin d'être capable de déchiffrer le jeton ou de le comprendre d'une autre manière. Il le prend juste et l'ajoute à chaque demande faite contre l'hôte WOPI. D'autre part, l'hôte WOPI doit pouvoir valider le jeton. Le jeton indique les ressources auxquelles l'utilisateur donné a accès. Assurez-vous de bien le concept du access_token. Notamment:
Les jetons d'accès doivent être limités à une seule combinaison utilisateur et ressource.
La façon dont vous générez le jeton dépend entièrement de vous. Généralement, vous demandez à votre utilisateur/magasin de rôles (il peut s'agir de Windows ACL store, votre base de données ou autre) si l'utilisateur donné a accès à une certaine ressource et stocke cette information (revendications) dans le jeton et le crypter (donc qu'il ne peut pas être truqué). Une autre option consiste à inclure uniquement les informations sur l'utilisateur et laisser l'hôte WOPI déterminer l'autorisation lors de la validation du jeton (parler à l'utilisateur/magasin de rôles) ... cela est également possible car, comme je l'ai mentionné précédemment, le client WOPI ne t attention à ce qu'il y a dans le jeton. Vous pouvez même définir le access_token=xyz et ne jamais le vérifier dans votre hôte WOPI si vous ne vous souciez pas du tout d'autorisation.
Le processus de génération et de validation des jetons est très bien démontré dans OfficeDev/PnP-WOPI. Voir les classes HomeController et WopiSecurity.
Vous pouvez voir d'autres exemples dans mon autre réponse here.
