I am able to retrieve refresh tokens for my custom B2C policies but would like to increase the token lifetime to the max limit or set the sliding window lifetime to No Expiry.
This was able to be done via the Azure Portal B2C settings for Basic policies but is not available in the portal for custom policies.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-token-session-sso#token-lifetimes-configuration
How can I configure this in my policies?
Check out this article.
Specifically add the following in your RP technical profile.
<Item Key="token_lifetime_secs">3600</Item>
Can look like this (copied from docs)
<ClaimsProviders>
<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>
</ClaimsProviders>
What Parakh said is correct but please take note of the banner on the page that he linked to which says the following about SPA apps with PKCE:
Note
Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours while mobile apps, desktop apps, and web apps do not experience this limitation. Learn more about the security implications of refresh tokens in the browser.
That means that settings such as the following may not be respected for those apps:
refresh_token_lifetime_secs
rolling_refresh_token_lifetime_secs
allow_infinite_rolling_refresh_token
This last one is never respected for SPA w/ PKCE
Related
We are trying to integrate custom identity provider like NHS Login with Azure ADB2C which provides private key to fetch access token. When we try to login using credentials, we get the error saying "We encountered an error connecting to the identity provider. Please try again later." Is there any source or starting point which we can refer where user has integrated generic custom identity provider like NHS Login with Azure ADB2C successfully and able to fetch access token using private key as token endpoint auth method Azure ADB2C tech profile
(new account so can't comment on the above - but i think the below is useful to this thread).
Jas Suri, Could you possibly expand on the last sentence please, as from what I've experienced, its a requirement?
It is best to use the OAuth2 technical profile to get the most out of
NHS Login platform
I have now got NHS Login working with Azure B2C, but I had initially had the claims tech profile setup as OpenIdConnect, but was getting validation errors:
(IDX10618:
AsymmetricSecurityKey.GetHashAlgorithmForSignature( 'RS512' ) threw an
exception.\nAsymmetricSecurityKey:
'System.IdentityModel.Tokens.RsaSecurityKey'\nSignatureAlgorithm:
'RS512', check to make sure the SignatureAlgorithm is supported)
We have integrated NHS Login with AAD B2C.
The document linked shows two metadata items that make us compatible with NHS Login:
token_endpoint_auth_method: Specifies how Azure AD B2C sends the authentication header to the token endpoint. Possible values: client_secret_post (default), and client_secret_basic (public preview), private_key_jwt (public preview).
token_signing_algorithm: Specifies the signing algorithm to use when token_endpoint_auth_method is set to private_key_jwt. Possible values: RS256 (default) or RS512.
The technical profile will look like this:
<TechnicalProfile Id="NHS-Login-OAUTH2">
<DisplayName>NHS-Login-OAUTH2</DisplayName>
<Description>Login with your NHS account</Description>
<Protocol Name="OAuth2" />
<Metadata>
<Item Key="authorization_endpoint">https://auth.sandpit.signin.nhs.uk/authorize</Item>
<Item Key="AccessTokenEndpoint">https://auth.sandpit.signin.nhs.uk/token</Item>
<Item Key="ClaimsEndpoint">https://auth.sandpit.signin.nhs.uk/userinfo</Item>
<Item Key="client_id">yourClientIdFromNHS</Item>
<Item Key="scope">openid email profile phone profile_extended gp_integration_credentials</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
<Item Key="response_types">code</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="token_endpoint_auth_method">private_key_jwt</Item>
<Item Key="token_signing_algorithm">RS512</Item>
</Metadata>
<CryptographicKeys>
<Key Id="assertion_signing_key" StorageReferenceId="B2C_1A_NhsSandpit" />
</CryptographicKeys>
..snip..
NHS Login requires private_key_jwt and RS512. This will use a client assertion to authenticate to the NHS Login /token endpoint.
Take the PEM file which NHS login docs state to generate, and convert it to PFX. Upload that PFX into B2C policy keys. This is referenced in the CryptographicKeys node of the technical profile.
It is best to use the OAuth2 technical profile to get the most out of NHS Login platform.
We are experiencing issues completing the sign out flow using Azure B2C with custom policies.
We have created a sample Enterprise Application in our Azure AD and set it up as a federated identity provider in our custom policies in the B2C environment, besides the sign out issue everything works as expected.
The sign out flow.
The first step works well and the session is cleared on the B2C identity provider.
We can see in the network tab that the correct endpoint is called on the federated identity provider, but this request is blocked (net::ERR_BLOCKED_BY_RESPONSE) I then checked the response header and found X-Frame-Options: DENY. I am unsure but to me it looks like the request is made from an iframe but is blocked.
The user is redirected back to the app's post_logout_redirect_url
A workaround is to put the end_session_endpoint as the post_logout_redirect_url:
https://domain.b2clogin.com/domain.onmicrosoft.com/signin/oauth2/v2.0/logout?post_logout_redirect_uri=https://login.microsoftonline.com/guid/oauth2/v2.0/logout?post_logout_redirect_url=https://app.com/callback.html
and that works fine.
Here is the technical profile
<TechnicalProfile Id="Company-OpenIdConnect">
<DisplayName>Company</DisplayName>
<Description>Company</Description>
<Protocol Name="OpenIdConnect"/>
<Metadata>
<Item Key="METADATA">https://login.microsoftonline.com/tenantID/v2.0/.well-known/openid-configuration</Item>
<Item Key="client_id">guid</Item>
<Item Key="response_types">code</Item>
<Item Key="scope">openid profile</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
</Metadata>
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
</TechnicalProfile>
This is expected, most IdPs will not allow to be rendered in an iframe for login or logout. Azure AD does not allow to be rendered in an iframe either, hence the logout does not complete.
Your workaround causes a full page redirect, which will work, but the user experience maybe jarring.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-custom-policy#sign-out
The sign-out clears the user's single sign-on state with Azure AD B2C, but it might not sign the user out of their social identity provider session.
I'm trying to add a custom policy without refresh token
I've modifiy the ClaimsProviders this way :
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="JwtIssuer">
<DisplayName>JWT Issuer</DisplayName>
<Protocol Name="None" />
<OutputTokenFormat>JWT</OutputTokenFormat>
<Metadata>
<Item Key="client_id">{service:te}</Item>
<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item>
<Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
<Item Key="token_lifetime_secs">3600</Item>
<!-- 1 H -->
<Item Key="id_token_lifetime_secs">3600</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims />
<OutputClaims />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
But it's not working.
I'm facing this js error when I try to sign in :
main.js:1 ERROR ServerError: server_error: AADB2C: Issuer technical profile 'JwtIssuer' must specify a 'issuer_refresh_token_user_identity_claim_type' to use this OAuth flow
Correlation ID: bab26044-1e53-4b4a-b5c9-d2f35030a9d7
Any ideas ?
Thanks :)
Thanks for the comment #paralight. We need to apply some workaround to achieve the same as there is no way to remove the refresh token and no direct modifications to the JWTIssuer technical profile.
Workaround:
Force a session time out by adding a tag UserJourneyBehaviors in custom policy. ex :
<UserJourneyBehaviors> <SingleSignOn Scope="Application" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>900</SessionExpiryInSeconds> </UserJourneyBehaviors>
Other scenario :
Claims information in the JWT token is exposed to the public. To store some sensitive information in the JWT token
Workaround: You can send claims to a REST API and send them back to B2C to encrypt.
You would create an orchestration step before the SendClaims step to send all claims to a REST API, and have the REST API respond with encrypted versions of those claims
JWT Token issuer reference https://learn.microsoft.com/en-us/azure/active-directory-b2c/jwt-issuer-technical-profile
REST API usage https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-claims-exchange
Reference : All Technical Profiles : https://learn.microsoft.com/en-us/azure/active-directory-b2c/technicalprofiles
Reference SO Thread: Modify the JwtIssuer ClaimsProvider in the custom policy to achieve the JWE in AD B2C
Adding your comment as answer and glad to know your queries are addressed. You can accept it as answer( click on the check mark beside the answer to toggle it from greyed out to filled in). This can be beneficial to other community members.
I am trying to use the following article to get ADFS working with Azure AD B2C in the start almost 3 weeks ago it worked and now I am getting this error.
AzureAD B2C ADFS Configuration
The Error I get after providing the credentials into ADFS.
AADB2C90168: The HTTP-Redirect request does not contain the required parameter 'Signature' for a signed request.
I removed my Custom policy and took on a vanilla policy from starter pack and configured ADFS but had the same result.
There is no guidance on AADB2C90168 on the Internet on this error.
For info
The ADFS is using a Public certificate and AzureAD B2C is using a self-signed certificate (as described in Pre-Requisites section).
Any help will be appreciated.
Turning off response signature checking weakens security, so probably not a good idea.
Azure B2C is expecting both the message and the assertion to be signed. By default, ADFS only signs the Assertion.
Run this on your ADFS Server:
Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion
In your technical profile for ADFS, add the following key <Item Key="ResponsesSigned">false</Item> to the metadata to see if this corrects your issue or not?
<TechnicalProfiles>
<TechnicalProfile Id="MyADFS-SAML2">
<DisplayName>MyADFS</DisplayName>
<Description>Login with your MyADFS account</Description>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="RequestsSigned">false</Item>
<Item Key="ResponsesSigned">false</Item>
<Item Key="WantsEncryptedAssertions">false</Item>
<Item Key="PartnerEntity">https://sts.myadfs.com/FederationMetadata/2007-06/FederationMetadata.xml</Item>
</Metadata>
...
</TechnicalProfile>
</TechnicalProfiles>
Background
I have an application in which users signup/sign through AD B2C. In the application, there is a link which will redirect to another application which works on SAML so want MS Azure to work as IDP and sends SAML to the third application.
We achieved this in AAD (not AD B2C) through the non-gallery application but getting problems in AD B2C.
We followed this document https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Walkthroughs/RP-SAML.md
but when we hit the URL then it says "AADB2C: An exception has occured".
Base file - https://www.dropbox.com/s/ro6arbs57c43el2/base.xml?dl=0
Extension file - https://www.dropbox.com/s/uqojtk432b3wny1/base_Extensions.xml?dl=0
SignInSaml file - https://www.dropbox.com/s/i950s4bwwagry5k/signinsaml.xml?dl=0
The best thing you could do is work with OIDC first and confirm the policy is working and then overwrite the step where you issue a JWT token with SAML
When working with SAML i have this format
Base
Base-extensions (if you want it - i tend not to)
policy-OIDC (This extends base)
policy-SAML (This extends OIDC)
In the policy SAML I then override my user journey orchestration step that calls the JWTIssuer and then call my SAML token creator
The reason for this approach is B2C has been designed to work with OIDC , you can confirm that the journey is working as expected in OIDC and then switch to your SAML
Id also use the journey recorder, I find the older B2C journey recorder you get better than app insights but both track the same data
After checking my SAML in the office your missing some META data to tell SAML how to behave in your policy
<Metadata>
<Item Key="IdpInitiatedProfileEnabled">true</Item>
<Item Key="RequestsSigned">false</Item>
<Item Key="WantsSignedResponses">true</Item>
<Item Key="ResponsesSigned">true</Item>
<Item Key="AssertionsEncrypted">false</Item>
<Item Key="WantsEncryptedAssertions">false</Item>
<Item Key="PartnerEntity">https://my-calling-application/authservices</Item>
</Metadata>
<SubjectNamingInfo ClaimType="UserId" />
Your SubjectNamingInfo will also need to be
http://schemas.microsoft.com/identity/claims/userprincipalname
as this is the SAAML name you defined in your base policy