Showing results for 
Search instead for 
Did you mean: 
Frequent Visitor

Configuring authentication with Dynamics 365/PowerApps Portals

I noticed that the Authentication capability is now enabled for Power Virtual Agent, so tried to play with it to see how it works in the context of Dynamics 365 Portals/PowerApps Portals. I am able to successfully configure the Authentication parameters and was able to update my topic to enable the authentication actions.


The problem point is that the PVA wants to use the redirect_uri = and it constucts the authorize request as "https:/


This fails on the portal as the portal expects a valid portal url as the redirect_uri.


For my troubleshooting purposes, I modified the "Authorization URL Query String Template" to hardcode the portal's home page url and this time, the portal authorizes the request and gets the token as expected. But the entire Portal page where the bot is embedded gets refreshed when I click on the "Authenticate" button, hence I lost the context of the bot's authentication.


Can the PVA be configured to be authenticated with Dynamics 365 Portals? Am I missing something here? 





Accepted Solutions

There's also a post from Natraj Yegnaraman on authenticating against CDS.





View solution in original post

Resolver I
Resolver I

Hi Dhina,


Can you authenticate and redirect to the Bot?

I get a 400 BadRequest after I login and it redirects to


Everything seems configured correctly 




Frequent Visitor

Hi Joe,

I am not getting authenticated and redirected to the bot as well.

I can confirm that the authorization token is returned successfully by the portal when the user clicks on "Login" button in the PVA. But the redirect is where it is failing.


Couple of things I changed (deviated from the documentation) in the authentication configuration to suit portal's needs so as to get the authorization token back.

1. From the Authorization URL Query String Template, I removed the "state" query parameter as the portal only accepts 20 characters as part of the state, but PVA generates more than 20 characters, so the authorization fails.

2. In the Authorization URL Query String Template, the "redirect_uri" query parameter has "{RedirectUrl}". Looks like the PVA replaces this with But this redirect_uri conflicts with Portal's needs as the Portal expects the Portal page url as the redirect_uri. So, I hardcoded my portal home page url so that the portal can return the authorization token, which it does successfully.


Where do you get the bad request error? On the portal ? Are there any detailed error message?

If it helps, I am open to meeting with you in Teams or any other channel to take this forward as well.



New Member

Hi Dhina & Joe,


Any resolutions ? I'll too get the same bad request error, when I tried to add to Portals.



Pradesh Dhayalan



I am getting a 400 when it redirects to 

with the auth code being passed as the query sting


I have  not had a chance to try anything else but it looks like other people are having the same problem so its not just me.


I will try a few other things over the next few days and if I make any progress I will post it here




Not applicable

Still nothing, Pradesh. I’ll keep the thread posted if I find anything new.

BTW, what is the detailed error that you get ?


Nothing obvious in my response


Request URL:
Request Method: GET
Status Code: 400
Remote Address:
Referrer Policy: no-referrer-when-downgrade
content-length: 11
content-type: text/html
date: Mon, 18 Nov 2019 07:03:57 GMT
status: 400
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
:method: GET
:path: /.auth/web/redirect?code=XAQABAAIAAACQN9QBRU3jT6bcBQLZNUj7TieMYSJWXPov_qHD5TX7HOgVlZrF1PF4WUvyhTo4a4HfM6kGzaRy7aN8ERNg3laxIBbLCBsBx5pulstr3XWz_2zN05UOHAheFQhurFevkTQ-xMEEM7YDCBZvZP09bnj_TVpiP-CEhnYqpYtkVtz8TjRh6H_IfFI0HD0zXjtGuPf0DqUAppjiLMYZS9wX1wbHjTu8XVEk2coH9i7OlkiTF1NqBXOgx1ECDRCNlauZUVixmlvVQnhTtnWPCML1wDBMeDDSGGdOX0iLxrVhmRrddKr7w82dBrlrWs-GWrqvWf49bIh3gowr9b-uJSMdFPXteW-T3AN0b_bM0iPm_Ed3jWvBkaZ_x4vjxR1Fw-wltGl8zWXDHO97fQngPg7ueDcGBdsx2w08K99C_vU8T4QjezJ9K42URZClNZG_MSffcQpS23mOLWoaN3_rSOVfspl7F5q7lhiRzjhIeu4IT2b1cSvCWZjyf3KvZiewXo6QY1vFaEYd_Y0e466V8pLnkgdeva5UBEG4tBZ86wzhVExkUDJIcdaeF_s4ReSsiELdnDQ6Qq-J8zATkEJryzAPBu043b5Gg9Ihf-bjkHJllUzYDBgTUlJ3uz6pTM7I8nfSa3AgAA&state=06fcb9b20ba343d497e020a8919b2290&session_state=d7cc9a60-59da-4edd-a700-c2bce4fcc9a6
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
accept-encoding: gzip, deflate, br
accept-language: en,en-US;q=0.9
cache-control: max-age=0
cookie: _ga=GA1.2.1702478537.1570347507; consent06fcb9b20ba343d497e020a8919b2290=ew0KICAicG9zdExvZ2luUmVkaXJlY3RVcmwiOiAiaHR0cHM6Ly90b2tlbi5ib3RmcmFtZXdvcmsuY29tL2FwaS9vYXV0aC9Qb3N0U2lnbkluQ2FsbGJhY2s/c2lnbmluPTZmYjBiMDYxYTk0NTQ4N2RiZDg2MjZjNTAzZDQxNGZkJmNvZGVfY2hhbGxlbmdlPSIsDQogICJsb2dpblNldHRpbmdJZCI6ICIwNjA5MWQxZi1lZjM3LWE4YzktMjlkMC02MDMyMzU2MTAyOTBfZGY4NzRhOGQtZTA5NS03NzVhLTZhYjMiDQp9
sec-fetch-mode: navigate
sec-fetch-site: none
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
code: OAQABAAIAAACQN9QBRU3jT6bcBQLZNUj7TieMYSJWXPov_qHD5TX7HOgVlZrF1PF4WUvyhTo4a4HfM6kGzaRy7aN8ERNg3laxIBbLCBsBx5pulstr3XWz_2zN05UOHAheFQhurFevkTQ-xMEEM7YDCBZvZP09bnj_TVpiP-CEhnYqpYtkVtz8TjRh6H_IfFI0HD0zXjtGuPf0DqUAppjiLMYZS9wX1wbHjTu8XVEk2coH9i7OlkiTF1NqBXOgx1ECDRCNlauZUVixmlvVQnhTtnWPCML1wDBMeDDSGGdOX0iLxrVhmRrddKr7w82dBrlrWs-GWrqvWf49bIh3gowr9b-uJSMdFPXteW-T3AN0b_bM0iPm_Ed3jWvBkaZ_x4vjxR1Fw-wltGl8zWXDHO97fQngPg7ueDcGBdsx2w08K99C_vU8T4QjezJ9K42URZClNZG_MSffcQpS23mOLWoaN3_rSOVfspl7F5q7lhiRzjhIeu4IT2b1cSvCWZjyf3KvZiewXo6QY1vFaEYd_Y0e466V8pLnkgdeva5UBEG4tBZ86wzhVExkUDJIcdaeF_s4ReSsiELdnDQ6Qq-J8zATkEJryzAPBu043b5Gg9Ihf-bjkHJllUzYDBgTUlJ3uz6pTM7I8nfSa3AgAA
state: 06fcb9b20ba343d497e020a8919b2290
session_state: d7cc9a60-59da-4edd-a700-c2bce4fcc9a6



I am not much familiar with authentication flows supported by Dynamics 365,but when I looked in to documentation @, I think Dynamics 365 only supports implicit auth flow.

Whereas the user authentication through PVA expects to use Authorization Grant flow. After looking in to "response_type" param in below URL, it looks like you were also trying to make implicit flow work through PVA which is not possible or supported.


To make user authentication work through PVA, authorization code needs to send by IDP to which will eventually fetch access token using authorization code and client credentials.



Frequent Visitor

You are right. D365 Portal only supports Implicit Grant Type and I modified the template to make it work with Implicit Grant Type.

hmm.. Guess I got too excited and took the word "template" a little too far.


Then it comes down to portals not working with the PVA as far as the authentication goes. It is a little weird though as I would have expected this feature to work on the Portals as both are at the same level and typical demo scenario of these PVAs would be D365 Portals.



Regular Visitor

I get the same 400 Bad Request, no details.

Have you figured out the problem?

Helpful resources

Community Connections 768x460.jpg

Community & How To Videos

Check out the new Power Platform Community Connections gallery!

Carousel 2021 Release Wave 2 Plan 768x460.jpg

2021 Release Wave 2 Plan

Power Platform release plan for the 2021 release wave 2 describes all new features releasing from October 2021 through March 2022.

M365 768x460.jpg

Microsoft 365 Collaboration Conference | December 7–9, 2021

Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.

Center-of-Excellence-Starter-Kit-cropped 768x460.png

The Total Economic Impact™ of Power Virtual Agents

Read this 2021 commissioned study, conducted by Forrester Consulting.

Top Solution Authors
Top Kudoed Authors
Users online (2,539)