I have configured the Refresh token lifetime to 90 days, but when the token returned by Azure AD B2C was always 24hrs only. Is there anything specific I need to do to extend the token lifetime?
This is an expected scenario for PKCE flow
As per MS Document,
The single-page applications using the authorization code flow with
PKCE always have a refresh token lifetime of 24 hours.
Related
I have a cognito User Pool with 1 client that is configured with 2 identity providers, Cognito User Pool and a SAML provider that links an Azure AD instance. The Allowed OAuth Flows is set Implicit grant only. Login via the Cognito User Pool provider is done using the InitiateAuthCommand in the #aws-sdk/client-cognito-identity-provider library. From this an id_token, access_token and refresh token are all returned.
Login via the SAML provider is done by using the template link provided in the cognito developer docs (https://your_Amazon_Cognito_userpool_domain/authorize?
response_type=code&identity_provider=your-SAML-IdP-name&client_id=your-
client-id&redirect_uri=https://your_application_redirect_url). This login works, however only an id_token and access_token are returned (no refresh token).
How can I get cognito to issue a refresh token for users logged in via the SAML provider
Cognito should not return a refresh token for Implicit grant flow. That is the intended behaviour according to the specification:
The authorization server MUST NOT issue a refresh token.
Also using the implicit flow is highly discouraged due to vulnerabilities.
Please consider using Authorization code grant flow along with PKCE. With that you can get the refresh token.
The reason you get the refresh token along with the aws-sdk is, because it should be using a different Auth flow (example: USER_PASSWORD_AUTH) as mentioned in the document.
I thought this would be a simple Google but I cant seem to find an answer.
When an invitation email is sent from Azure AD B2C (Active Directory Business to Consumer), how long is the emailed link valid for before it can no longer be redeemed?
Is this configurable anywhere?
Thanks
To invite a user, from the application, we will type the user's email address and click Send invintation. The application sends a sign-in link (with a id_token_hint). User clicks on the link, that takes to user to Azure AD B2C policy.
The key to sending data to Azure AD B2C custom policy is to package the data into a JWT token as claims using id_token_hint. In this case, we send the user's email address to Azure B2C. Sending JWT token requires to host the necessary metadata endpoints required to use the "id_token_hint" parameter in Azure AD B2C. The id_token_hint must be a valid JWT token. The token contains the claims that are mandatory.
So inside the token we have claim called exp(Expiration time): The time at which the token becomes invalid, represented in epoch time. Azure AD B2C validates this value, and rejects the token if the token is expired.
Token Format and claims
Reference
I'm using the adal-angular5 v1.0.36 client library to authenticate my web application to Azure Active Directory.
The thing is that my session lasts 1 hour (the default expiration time) and I'd like to "renew" it silently for the user once it has expired; i.e. without having to ask the user for the credentials again or logging out and then login again (which would cause work loss for the user).
Is this possible to achieve?
As long as the user have an active session with Azure AD, ADAL JS does it automatically for you. ADAL JS examines the projected expiration of the existing token (in the cache) and if the token is about to expire, it uses an invisible iFrame to send a new token (renewal) request to Azure AD.
Please choose MSAL over ADAL and here is the sample for angular using MSAL.
Please refer the link for migration of ADAL to MSAL
Currently, the implicit grant flow URL to get access tokens from Azure AD by our SPA (native web app running in Azure VM) is of the format:
https://login.microsoftonline.com/{{tenantID}}/oauth2/authorize?response_type={{responseParams}}&client_id={{applicationID}}&redirect_uri={{redirectUri}}
Here, responseParams= id_token is the default value passed by Adal.js. What would be the changes needed to be made to this URL to get back refresh tokens from Azure AD?
The implicit grant flow does not issue refresh tokens, mostly for security reasons. A refresh token isn’t as narrowly scoped as access tokens, granting far more power hence inflicting far more damage in case it is leaked out. In the implicit flow, tokens are delivered in the URL, hence the risk of interception is higher than in the authorization code grant.
However, a JavaScript application has another mechanism at its disposal for renewing access tokens without repeatedly prompting the user for credentials. The application can use a hidden iframe to perform new token requests against the authorization endpoint of Azure AD: as long as the browser still has an active session (read: has a session cookie) against the Azure AD domain, the authentication request can successfully occur without any need for user interaction.
This model grants the JavaScript application the ability to independently renew access tokens and even acquire new ones for a new API (provided that the user previously consented for them. This avoids the added burden of acquiring, maintaining, and protecting a high value artifact such as a refresh token. The artifact that makes the silent renewal possible, the Azure AD session cookie, is managed outside of the application. Another advantage of this approach is a user can sign out from Azure AD, using any of the applications signed into Azure AD, running in any of the browser tabs. This results in the deletion of the Azure AD session cookie, and the JavaScript application will automatically lose the ability to renew tokens for the signed out user.
Reference: Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
Background
We are developing a multi-tenant SaaS product in Azure which has an AngularJS front-end and Web API back-end. We use Azure AD for authentication and have hooked it up with ADAL JS (using the OAuth2 implicit grant). Being a multi-tenant application, we allow customers to authenticate against their own Azure AD (which may or may not be connected to an on-premise AD).
So far this all works nicely. ADAL JS takes the user to the Azure login page and once the user has authenticated, an OAuth2 token is issued. This JWT token is then sent with all API calls as a bearer token where we have our own claims transformation process for mapping the incoming claims from Azure to our application claims.
Rather than specify individual users in the claims transformation process, we try to do it by AD groups. This allows our customers to have security groups in their AD and then our application will use that to map to the correct application claims.
The problem
The JWT token we receive does not contain a groups property, despite having set groupMembershipClaims to SecurityGroup in the AAD application manifest. I have since read in this tweet from Vittorio that
The implicit grant will NOT send those claims, as it returns the token in the querystring - it's easy to blow past max length
Upon further investigation, I also found this StackOverflow answer from Vittorio that says
I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups.
I had a look at the JWT token and it does not include any overage claim (identified by _claim_names and _claim_sources). I'm definitely a member of two groups in my Azure AD.
I also now appear to have two conflicting statements about whether it is possible to get group information (whether directly or indirectly) in the implicit grant token.
Question 1: Should I get an overage claim that I can use to get group information? If so, do I need to do anything to ensure that claim gets sent to me?
Graph API
Whether I can get an overage claim with a link to the user in the graph API or whether I have to manually craft the link to get the user's groups, I'm still a little unsure how I authenticate with the graph API.
I need to contact the graph API from the back-end after receiving a request with a bearer token (from ADAL JS).
Question 2: Can I send the same bearer token to the graph API to read that user's directory information? Or do I need to authenticate directly from my application to the graph API tenant in the context of the application rather than the user?
apologies for the confusion here. I will double check the statement about the overage, but in any case - for the sake of unblocking you quickly, let's assume that you need to get the groups manually without the aid of the overage claim. You cannot reuse the token you send to your Web API. That token is scoped to your app, and any other recipient will (or should) reject it. The good news is that the flow through which your backend can request a new token scoped for the Graph is easy to implement. See https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet - the details in your case are a be a bit different (your web API has the audience == clientid of your app) but the topology and the code/calls involved are exactly the same. HTH! V.