Power Automate Flows naming for documentation

I was recently shown this format and I think it's fantastic.  I'm moving all my flows to this Action naming approach:

Format: <Original OOTB name of the Action> | <Verb on Noun> 

Also, see my Flow tips here

Delegate Permssions - AAD app registrations

Overview: Application Registrations are primarily used to allow access to a system on a user's behalf. 

The best example is MS Graph, where you register an app to work on behalf of the current user.  So, if I need access to Outlook or a user's profile, I register an app, and the user must approve the request for these permissions when they access the app (assuming a code flow).  Some access is granted automatically, while more powerful access requires an administrator's consent/approval.

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: