I am using connected system with Oauth2.0 to connect to office365 and get the calendars i m able to authorize using connected system however when testing the base url I get the below error
Invalid credentials
Appian was not able to authenticate with the access token you provided. This request requires Bearer authentication. HTTP/1.1 401 Unauthorized Next Steps
When i run the authorization its executes successfully. Has any one seen this issue before or can someone share the Oauth2.0 configuration related to outlook ( For outlook defining a scope is mandatory)
Discussion posts and replies are publicly visible
It depends, you need appian and Outlook/Azure team to collaborate to integrate it.
I need Outlook/Azure team? can you please explain that to me if it's not a bother
You need your Azure team to create a connected system on Azure, grant access to outlook features, create graph API for outlook , provide credentials and API tokens your appian team will use the tokens as a constant to be able to connect to API, create process models and other objects to use outlook data.
Thanks for the info.
Hi Steve. Great info here. We are implementing this in Appian 19.2 using a connected system but it seems that we need to use an authorization link to obtain the token. This is an extra step for our users and needs to be repeated after each time the token expires. Is there any other approach that will not require the users to authorize every time? Do we just need to increase the token expiration value?
My write-up above is for the OAuth 2.0 Client Credentials grant type (which Appian now has a feature to handle OOTB rather than doing the 2 calls by hand: https://docs.appian.com/suite/help/19.2/oauth_client_credentials.html). This is for system to system (service account) type interactions. The system takes care of token retrieval and refresh; the user never knows). Also, Appian has access to all the data in the external system and decides who to show it to on Appian interfaces based on their Appian groups.
You seem to be talking about something different. Per-user authorization using authorization links is called OAuth 2.0 Auth Code grant type (which Appian also has features for: https://docs.appian.com/suite/help/19.2/Oauth_connected_system.html). This is what you are describing. If you go with this option, you HAVE to have the user manually authorize Appian to act on their behalf the first time and each time the token expires. That is how OAuth is designed and with good reason.
Hi Steven,
Good day.
Could you please explain a bit on the below:
Getting the bearer token
https://login.microsoftonline.com/<INSERT_ORG_SPECIFIC_URL>/oauth2/v2.0/token
(INSERT_ORG_SPECIFIC_URL)
This is the Microsoft URL that supplies the token: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#request-an-authorization-code
I know that this is quite an old topic at this point, but since this appears to be the best source I can find on it (and we are trying to do as you describe, call the Office 365 REST APIs to be able to do some things that the Graph API cannot), I figured I would ask.
When you mentioned 'using a plugin for the JWT', was that perhaps the createjwttokenwithrs256 plugin available on the App Market? I have not been able to get the plugin to accept any pkcs8 file I give it, but I have kept trying.
Additionally, I have tried uploading my self-signed certificate into Appian in the 'Client Certificates' admin console settings page, but I cannot find any documentation on how to reference this uploaded certificate within a Integration object or Connected System object (is it by the 'thumbprint'? Is there an example somewhere I could use?).
Thank you for your time.
The plugin we used was created for the project and is not available on the AppMarket. If that plugin allows for creation of JWT with the details Azure requires, then it might be a suitable solution, but I am not sure if Azure accepts pkcs8.
Client certificates in the Admin Console are for mutual authentication and Appian presents a certificate that matches the root of the server requesting mutual auth. This only happens when making a supported call in Appian (integration object or web service query). This is different than the JWT authentication that Office 365 REST APIs require.