You don't necessarily need to implement the /wopibootstrapper
endpoint nor the GetNewAccessToken
method. They're specific to the Office Online (365) integration program.
Your job is just to generate an access_token
that would be included in a POST request of the WOPI frame in your application (similarly to the picture in your question).
This token will be used by the WOPI client (WAC/OWA/OOS Server). The WOPI client doesn't need to be able to decipher the token or understand it in any other way. It just takes it and appends it to every request being made against the WOPI host. WOPI host, on the other hand, needs to be able to validate the token. The token say which resources the given user has access to. Make sure you understand the concept of the access_token
well. Especially:
Access tokens must be scoped to a single user and resource combination.
How you generate the token is entirely up to you. Typically, you'd ask your user/role store (this can be Windows ACL store, your database or something else) whether the given user has access to a certain resource and store this information (claims) within the token and encrypt it (so that it can't be faked). Another option is to include just the information about the user and let WOPI host figure out the permission during token validation (talk to the user/role store)...this is also possible because, as I mentioned earlier, the WOPI client doesn't care what's in the token. You can even set the access_token=xyz
and never check for it in your WOPI host if you don't care about authorization at all.
The process of generating and validating tokens is very well demonstrated in OfficeDev/PnP-WOPI. See the HomeController
and WopiSecurity
classes.
You can see some other examples in my other answer here.