Skip to main content

We have created Html custom component with JS script to retrieve all messages of a Teams chat, it is loaded in a preview screen.We managed to retrieve all messages of a given chat and show them.For logged user that participates in the chat we what to give them he option of deleting there messages.

In the script we are trying to authenticate the user with OAuth2.0 similar to how Oauth user login process action works. The only difference is that a state parameter is generated for the login URL session an is included in the URL query string , also as a parameter. We tried generating a state GUID in the same format hat the process action provides in the flow but we encountered this error:


--”The state parameter, 1dbfcd91-e154-4aaf-a71f-5b735aff11de, received from the OAuth server does           not point to an existing process flow resource.”

If we omit this parameter we get this error

--”Received state, 'null', from the OAuth server but it is not in the correct format. The expected state              format is a guid.”

Do you have any suggestion to how we can get access to the “state” parameter implement it in an oher way in JavaScript.

Hi,

The state parameter is used to allow Indicium to continue where it left off when the control flow went to the user to authenticate.

You cannot invoke the OAuth2 authorization grant flow from your own JS client in the browser and have the callback URL point to Indicium. Indicium won’t be able to know what to do with the callback.

Capturing the redirect yourself from a custom component can be difficult. Did you consider having Indicium handle the full OAuth2 grant flow and retrieve the access token from Indicium afterwards?

Ok, we thought about this solution as well ! 
Should we store and encrypt the access token in the db. and retrive it with an Api calls in JS since we needed it  for other api calls as well or do you suggest something else.

You can certainly encrypt the access token. Retrieving the unencrypted token will take some extra effort as it has to run through a decryption process action. The unencrypted token should never be present in (the memory of) the database.

The lifetime of this token should be limited, and the data should already be protected through the API via RBAC & data authorization as well as during transport via https.

Encryption of the access token can be used as an additional safety measure for defence-in-depth. Note that the main use case for this form of data encryption is to protect the data while at-rest. Given that the lifetime of the token is short, this attack surface is quite limited. For intruders with direct access to the database it will offer a layer of protection. For malicious parties who obtain a back-up of the database, the tokens will likely already be expired.

In short, it is up to you how far you want to go with your security measures.

Reply


Terms & ConditionsCookie settings