Access token renew fails with error AADB2C90077

[DavidHenri008]

Hi, I am experiencing issue trying to obtain a new access token from my B2C.
From my SPA I use the msal.js library (v0.1.3) to first authenticate to my B2C. After an hour, the access token expires so I do a silent token renew procedure but it fails. I receive the following error from the B2C:
AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'.
Correlation ID: XXXXXXX
I could not find any information concerning the caused of the error AADB2C90077.

Thanks.

David

[rohitnarula7176]

@DavidHenri008 The acquireTokenSilent uses a hidden iframe with prompt=none which means the user will not be prompted for credentials. This API relies on the session cookie established between the browser and AAD to obtain a new access_token. If your session is expired , this API call will fail and you will have to do an interactive token renewal by calling either acquireTokenPopup or acquireTokenRedirect where you will be asked to enter your credentials again. Closing this issue for now. Please reopen if you still have questions.

[DavidHenri008]

@rohitnarula7176 Ok, but when does the session expires? In my case my access token expires after an hour and it looks like my session cookie on the login.microsoftonline.com also expire within an hour. Is this possible? Is there a way to read the cookie content and read the expiration time?

[AnnaShk]

@DavidHenri008, you can parse token online using jwt.io

[DavidHenri008]

@AnnaShk I do not want to parse my access token, I want to parse the session cookie on the login.microsoftonline.com.

[DavidHenri008]

@rohitnarula7176 Can you tell me when the AAD session expires?

[DavidHenri008]

For the record, after multiple back and forth with Microsoft technical support and developers teams we finally identified the cause of my AADB2C90077 error code.
There was an issue in the Azure B2C backend where the default values were not handle properly by the system.
My workaround was to modify the four token lifetime values: ‘Access & ID token lifetime’, ‘Refresh token lifetime’, ‘Refresh token sliding window lifetime’ and the ‘Web app session lifetime’, in order for them to appear into the policy xml.

As of February 22nd 2018, Microsoft confirmed they issue a fix to solve this issue. So if someone has the issue it is most likely for a different reason.

[mrman888]

@DavidHenri008 can you please enlight your solution? Can you supply the exact policy xml?

[DavidHenri008]

@mrman888 as mentionned, today the issue is supposed to be fixed by Microsoft.
To be more precise on the issue, by default on a newly created B2C AD policy, all settings are not defined inside the policy xml. So if a value is not defined in the policy xml, the default system value is used which is supposed to correspond to the default value in the Azure Portal. The bug was that the default system value was NOT equal to the default Azure Portal value. So my workaround, described in my previous post, was a way to force the value to be defined in the policy xml.
The following settings, of a policy xml, were the one missing with the wrong default system values:

   <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="JwtIssuer">
          <Metadata>
            <Item Key="token_lifetime_secs">3600</Item>
            <Item Key="id_token_lifetime_secs">3600</Item>
            <Item Key="refresh_token_lifetime_secs">1209600</Item>
            <Item Key="rolling_refresh_token_lifetime_secs">7776000</Item>
            <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
            <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

[buildtestship]

I have an angular app and B2C exhibiting this exact same behaviour. I am unable to upload a new policy as per @DavidHenri008 so what is the fix?

In my instance I can login with loginRedirect and see the token in localstorage, but when trying to use token again the authcallback errors with this

Could not silently retrieve token from storage. AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'.
Correlation ID: 5a74e513-f690-435f-b430-3cfb6801ea69
Timestamp: 2018-03-21 23:46:27Z

There are literally seconds passing between redirecting from the login and seeing the token to issuing another request and getting this, so it is not a long time out issue

[DavidHenri008]

@buildtestship This really seems to be the same issue I experienced. Microsoft told me the bug has been solved on there side and it should not reappear. I suggest you try my workaround and on the four lifetime setting in Azure.

My workaround was to modify the four token lifetime values: ‘Access & ID token lifetime’, ‘Refresh token lifetime’, ‘Refresh token sliding window lifetime’ and the ‘Web app session lifetime’, in order for them to appear into the policy xml.

Let me know if it solves your issue.

[mrman888]

@DavidHenri008 do I need to pass in the offline_scope?

I added the JWTIssue claimsprovider as given solution. Also I have this in my relying party:

 <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
	<UserJourneyBehaviors>
      <SingleSignOn Scope="Tenant" KeepAliveInDays="1" />
      <SessionExpiryType>Rolling</SessionExpiryType>
      <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
      <ContentDefinitionParameters>
        <Parameter Name="ui_locales">{Culture:RFC5646}</Parameter>
      </ContentDefinitionParameters>
    </UserJourneyBehaviors>
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
       </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

My expiry time is still one hour:

{
"exp": 1521725615,
"nbf": 1521722015,
"ver": "1.0",
"iss": "https://login.microsoftonline.com/627de5e7-f8a1-4xxxxx584-8095-a6acd0xxx6a9ce1/v2.0/",
"sub": "a044410c-0541-4xxx1b2-b778-97axx541e5f6a9",
"aud": "968a7cc1-da99-40fdxxx-9cb6-7a01f5545e48",
"nonce": "bf8a4xd58-xx569e-4979-8103-886c21bf059b",
"iat": 1521xx722015,xx
"auth_time": x,
"given_name": "",
"family_name": "",
}

Here is my login request:
https://login.microsoftonline.com/te/mytentant.onmicrosoft.com/b2c_1a_signup_signin/oauth2/v2.0/authorize?response_type=id_token&scope=https://mytentant.onmicrosoft.com/myapp/read openid profile&client_id=96ccca7cc1-da99-40fd-9cb6-7a01f55ccc45e48&redirect_uri=https://mywebsite.azurewebsites.net&state=59336xx3d-e6e2-4111-9cca-5cde1db0694d&nonce=e2e43996-ee91-4506-8853-08fbc3xa1f746&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=0.1.5&ui_locales=EN&client-request-id=637xe1562-6be5-4f00-b034-183cx0b5a3c0c&prompt=select_account&response_mode=fragment

[DavidHenri008]

@mrman888 Your implementation seems right. My issue was related to the JwtIssuer missing values. Concerning the offline_scope I do not add it, I am not sure if it is added by the MSAL library, but I do not think so.

[nehaagrawal]

@DavidHenri008 confirmed that his issue was resolved "As of February 22nd 2018, Microsoft confirmed they issue a fix to solve this issue. So if someone has the issue it is most likely for a different reason."
Closing this issue.

[nathanrobinson]

For the record, after multiple back and forth with Microsoft technical support and developers teams we finally identified the cause of my AADB2C90077 error code.
There was an issue in the Azure B2C backend where the default values were not handle properly by the system.
My workaround was to modify the four token lifetime values: ‘Access & ID token lifetime’, ‘Refresh token lifetime’, ‘Refresh token sliding window lifetime’ and the ‘Web app session lifetime’, in order for them to appear into the policy xml.

As of February 22nd 2018, Microsoft confirmed they issue a fix to solve this issue. So if someone has the issue it is most likely for a different reason.

I just had this issue a year later and tweaking those values and saving the policy fixed it for me.

[abf7d]

@nathanrobinson, I'm new to custom policies and am trying to include those variables in my TrustedFarworkBase.xml under JwtIssuer. It doesn't fix the issue. Do you know if the variable names have been updated? T