AuthHub - IDP authentication response missing data

Products

• VIP Authentication Hub

Issue/Introduction

I have implemented IDP authentication flow for AuthHub portal. The response idpData (stored in session storage), is missing some pieces of data we may typically expect from a response. Below is an example of idpData from a successful Auth:

{

"flowState":<FLOW_STATE>,
 "userName":"xxxxxx",
 "userId":"32c7301c-3ed0-46ca-a019-3df0edd77695",
 "nextaction":"AUTH_ALLOWED",
 "id_token":<ID_TOKEN>,
 "additional":{
  "idpName":"My LDAP Test",
  "idpGuid":"2db2dc95-5a2d-4ee1-a005-27b5b12a5d30",
  "idpType":"ldap",
  "authLevelsData":{
   "a6d2d72f-ff28-497f-8a74-7b3c7671ba9b+XBBN6SF+1":"IDP/1523e644-2a19-43c6-97f8-6bd276b34c8c"
  },
  "currentFactorLevel":1,
  "amrForCompletedFactors":["FIDO"],
  "lastObligation":"IDP/1523e644-2a19-43c6-97f8-6bd276b34c8c"
 }
}

1. We would expect 'x-client-transaction-id' or 'x-transaction-id' or to be included in this data.

On our spring boot service, we have a proxy for factor credential submissions. This proxy will submit the credentials as normal. If the response contains AUTH_ALLOWED and an Id Token, then we will request a user access token which is returned to the front end. Is there any way to achieve something similar with the current implementation?

Environment

Release : 2.1.3

VIP AuthHub

Resolution

When processing a request, the response from Auth Hub( AH ) always includes "x-transaction-id" response header that AH clients can track for their own reasons. A client invoking AH API can indicate its correlation id by sending "x-client-transaction-id" http request header that AH will log.

The ID Token (OIDC IT) is issued by AH to represent the final authenticated identity and containing the "sid" (session id) that could be used for revoking if session tracking setting was enabled. That ID Token can be encrypted if required for confidentiality (controlled by client's app configuration).

There is no obligation on the client side to do anything with that IT, though most clients (or client agents aka client proxies) that need self service keep track of that IT to request AH ATs (via JWT-BEARER grant) to invoke user self service APIs.

So your proxy should be able to exchange IT for AT, with or without refresh token, and then keep using that IT or refresh token to re-request ATs as needed.