Custom HTTP connector in Power automate to POST x-www-form-urlencoded data

Problem:  As part of my OAuth process I need to swap and authorisation code for an Access Token using an API, the issue is that I need to get the token into PowerApps.  

Initial Hypothesis:  Initially I created an Azure Function that does the API post as it was the easiest.  But I reverted and thought it must be easier for me to have fewer working parts and as my solution used Power Automate and I've previously used Power Automate with the HTTP custom connector I'd use the same approach.  It proved fairly tricky to get the HTTP connector to work but with some playing around and clarification of my thinking it became rather straight forward.

Firstly, I need to ensure the API is working, so I use Postman:

Postman POST request using form-urlencoded.

When I get the 200 response, I wanted to see the underlying HTTP traffic so I opened Fiddler:

Solution: From the raw HTTP trace, I realised I needed to post the body in Power Automate in the correct format.  Key value pairs for parameters and separate with an Ampersand.  Also, Url's need to be escaped/encodes, in C# there are functions to encode and decode.  I needed to do the encoding using Find() and Replace() methods (sic).  From Power Automate, I return the Access token, refresh token and other info back to Power Apps.

More Info:

Uri.UnescapeDataString(String) Method (System) | Microsoft Docs

Understanding HTML Form Encoding: URL Encoded and Multipart Forms - DEV Community

Identity Server - OAuth and OIDC

Overview:  The current version of Identity Server is 4.  Identity server is basically a .NET Core 3.1 application that is an Identity Provider (IdP) similar in role to PingId, SiteMinder, AAD b2C.  Identity server allows applications (native mobile, websites and servers) to securely authenticate users.  In this post, OAuth means OAuth2.0.

OAuth2 Grant Types:

Flow	Description	Client	Grant Type
Authorisation with PK	Authorisation Code Grant Type.  Default choice for authorization.	Native mobile Apps, Windows app, Browser Apps	Code
Client Credential	Server-to-server (S2S) communication is also referred to as Machine-to-machine (M2M).	Server,Consoles,Services	ClientCredentials
Implicit	Instead, use the Authorisation Code Flow with PKCE (if possible)	Native Apps & SPA's often use Implicit Flow	Implicit
Hybrid
Device	Primarily for devices with limited input capabilities, it allows users to authenticate by entering a code on a separate device with a browser.	IoT devices, anything with limited input capabilities. Also can be for Native mobile Apps, Windows apps, and Desktop consoles.	Device
Resource Owner Pswd	Don't use

Scopes: The authorisation Server specifies the "scope" that the user has consented to.  So, for an API, you can limit the actions the user can perform.  Scopes must be unique strings.  Recommendation is to name your scopes by the API and the Verb, e.g. "pauls_api.read" is better than "read".  Scopes are used to give the user access to resources, so "read" is not a good idea.  Also, scopes have length limits, so don't be crazy verbose in naming.

Mandatory Endpoints:  OAuth specifies 2 endpoints, namely:

1. /authorization endpoint - gets the access grant and user consent (only code and implicit flows use this endpoint)
2. /token Endpoint - issues tokens (client credential only uses the token endpoint, obviously code & implicit flow use both endpoints)

Optional Endpoint Extensions:

• /revoke - used to revoke a token
• /userinfo - used to hold profile info for the user, e.g. name, email.  The /userinfo endpoint is used in OIDC implementations of OAuth and specifies that the user must use the following scopes: address, phone, email, and profile.
• /.well-known/oauth-authorization-server - useful to discover the actual OAuth implementation.

Tokens

Access Token:

• JSON Web Token (JWT), pronounced "JOT", is an access token that contains authorisation and profile data.  The alternative is to use Opaque to JWT, but most implementations use JWT.  
• JWT's need to be validated using the signature.  The JWT Access Token is base64 encoded and consists of three parts separated by period signs, i.e. , HEADER.PAYLOAD.SIGNATURE

Refresh Token:

• Refresh tokens are opaque
• Single endpoint with a single function to get a new Access Token.

Interactive description of the OAuth Code Flow process: