Azure Refresh Tokens - how are they used by HP Authentication Suite

 Here is a basic explanation on how we utilize Azure Authorization and Refresh Tokens for user sign-ins

On the first interactive sign-in, HP Authentication Manager (HPAM) or HP Secure Authentication Mobile app (HPSA) uses the OAuth 2.1 Authorization Code flow with PKCE against Microsoft Entra. As part of this sign-in, we request the offline_access scope, so Microsoft Entra issues both an access token and a refresh token.

The refresh token is used to silently obtain a new access token when the previous one expires, without requiring the user to perform interactive sign in again.

On the mobile app side, the mobile app (HPSA) stores the refresh token encrypted on the user’s device. It is used only to keep the user signed in when they return to the app after some time. If the refresh token becomes invalid, or policy requires re-authentication, the user is simply prompted to sign in again.

On the printer side, the printer app (HPAM) stores the refresh token in Microsoft Entra Custom Security Attributes (CSA) in v4, or in Keycloak in legacy mode. If the access token expires while the user is still signed in at the printer, HPAM silently refreshes it using the stored refresh token. Microsoft Entra returns a new access token and may also rotate the refresh token. HPAM continues the user session without interruption and updates the stored refresh token if required.

HPAM also uses the previously stored refresh token in NO-MFA mode. The process is the same: a new access token is obtained using the refresh token so the user does not need to complete another interactive sign-in.

For further clarification - Review https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens

Other Questions you may have

• How long does the refresh tokens last?
  
   Refresh token lasts 90 days. Every time we obtain new access_token we receive new refresh_token which lasts another 90 days.

• What forces tokens to be changed and or Updated?
  
   The Azure services can revoke refresh tokens because of a change in credentials, user action, or admin action. Please see the table here: https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens

• Does the refresh tokens have Data that tells when it needs to be refreshed?
  
   No - refresh tokens are opaque to us. HPAM attempts a silent refresh and if Entra rejects it (expired, revoked, policy change), HPAM falls back to interactive login (user name/Password/OTP/MFA passwordless etc.)

• Do you know if an IT person can force users to generate a New Refresh Token?

An IT admin can force this by:

• Removing or modifying the user’s encrypted refresh token in CSA or in KeyCloak (Not applicable to HPSA)
• Enforcing MFA or stricter Conditional Access rules
• Resetting the user’s password or sign-in sessions

This won't reset any of the card ID's, but simply a user would need to complete an interactive sign-in on next authorisation.

Removing card ID's from CSA or KeyCloak will force user to reregister their card.. 

• So do you know what changes will affect how long refresh token live for?
  We do not have control over refresh token lifespan but administrators could "revoke all refresh tokens for a user" according to the documentation. 

• Is the current refresh token we use Solely used for Pull Print and when customer chooses the NO MFA option.? 

It has nothing to do with Pull Print, we store refresh token to support our NO-MFA scenario only. Universal Print has it's own device tokens and able to fetch jobs from printer without having user being authorized when using _Pull Print mode.
  

• How does our Mobile App (HPSA) use Refresh Tokens for user Registration and BLE/QRCode?
  HPSA uses refresh tokens solely to keep users signed in when they return to the app after a period of inactivity. When needed, the app exchanges the refresh token for a new **access token**, which includes the appropriate scopes for secure communication with your SignalR service.

  
  

  During initial onboarding, HPAM securely listens to SignalR and processes the user’s first QR code scan. At that point, HPAM registers the mobile device and stores the user’s Unique QR Code Badge ID.

  
  

  If the user later enables Bluetooth Low Energy (BLE), their Unique BLE ID is also registered—either in CSA or in Keycloak, depending on the configuration. This ensures that both QR and BLE identifiers are tied to the same user account and can be used for authentication or access workflows.