Playwright Post 6 - Automating Canvas App MFA login for Playwright unattended for Canvas apps

Overview:  Modern security makes automating logins requiring MFA rather difficult.  This post looks at possible approaches to automate the login.

Option 1. Turn off MFA—not really, but you can set a conditional rule in EntraId to not perform MFA. This is not an option in many enterprises.

Option 2. Time-based One-Time Password (TOTP)—Microsoft Authenticator makes this pretty difficult. At least I can't do it, as the APIS are relatively limited. This is kind of expected, as it's a security measure.

Option 3. Programmatically acquire an access token without browser automation, use MSAL with a client secret or certificate (for confidential clients). 

Option 4.  Use Playwright to record the login and intercept the access token once logged in.  Then you can store it and use it.  There are a few easy options to get the session:

4.1. Retrieve the access token from the response once logged in

4.2. Retrieve from your local storage:

  const token = await page.evaluate(() => {

    return window.localStorage.getItem('adal.idtoken') || window.sessionStorage.getItem('adal.idtoken');

  });

4.3. Retrieve the token using Playwrite at the command run level

Note: This adds the token to my repository. Don't save the token to your repository if you don't realise that the Access/Bearer token will expire depending on what your EntraId sets. The default is 1 hour.

Option 4.3.1. Like option 4.3, use the refresh token to silently generate a new Access token. You store the refresh token during the recorded login (by default, it lasts for 90 days) to generate a new access token when you need it.

Option 4.3.2.  Take it further back to generate the refresh token using the access code you get at the original login, renew the "refresh token", and generate a new access token to run your tests.

If you decide to store your access token, refresh token or code, don't store them in your code repo.  You know why if you got this far.

Thought: as a refresh token works for 90 days on a sliding scale, I've never used the option 4.3.2, as by storing the refresh token, all I need to do is to extend the refresh token by using it to get an access token and the refresh token has 90 days from that point. 

This is the plan I'm thinking of using:

1. Store the refresh token in Azure Key Vault (AKV).
2. Your app retrieves the refresh token from AKV.
3. Uses the refresh token to get a new access token.
4. Store the new access token to run my ALM/CI/CD playwright tests

Playwright Series

Playwright Post 1 - Overview of E2E testing using Playwright

Playwright Post 2 - Continuously Test/Monitor Canvas apps and website with MFA enabled

Playwright Post 3 - Add App Insights logging inside your Playwright tests 

Playwright Post 4 - 6 Min walkthru of Playwright testing with Azure Monitor

Playwright Post 5 - Understanding how Playwright works

Playwright Post 6 - Unattended testing when secured with MFA (this post)

Personal Access Tokens (PAT)

Personal Access Token (PAT) are used a lot for automation in DevOps, once again need to lookup the informal on PATs.  I use Postman and I use PATs to automate connecting to Azure resources.

https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows

Store the PAT as it won't be retrievable again.

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 Identify Provider (IdP) similar in role to PingId, SiteMinder, AAD b2C.  Identity server allows application (native mobile, web sites and servers) to securely authenticate users.  In this post OAuth means OAuth2.0.

OAuth2 Grant Types:

Flow	Description	Client	Grant Type
Authorization with PK	Authorization Code Grant Type.  Default choice for authorization.	Native mobile Apps, Windows app, Browser Apps	Code
Client Credential	Server-to-server (S2S) communication also refereed to as Machine-to-machine (M2M).	Server,Consoles,Services	ClientCredentials
Implicit	Rather use the Authorization Code Flow with PKCE	Native Apps & SPA's often use Implicit Flow	Implicit
Hybrid
Device
Resource Owner Pswd	Don't use

Scopes: The authorisation Server specifies the "scope" that the user has consented too.  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 user must use: address, phone, email, profile in their scopes.
• /.well-known/oauth-authorization-server - useful to discover the actual OAuth implementation.

Tokens

Access Token:

• JSON Web Token (JWT) pronounce "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 base 64 encoded and are made up 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: