I've been trying to find how Azure B2C handles the token refresh when there is a third party IDP involved.
So, let's say I have an Azure B2C tenant, and I have added an identity provider configuration for a customer. Let's say that all users with the #customer.com email are redirected to 'Customer's' IDP for authentication. Lets say I have a mobile application which uses Azure B2C to obtain access and refresh tokens for an API that we own.
When the user accesses the mobile app for the first time, the mobile app redirects the user to Azure B2C. If there is no external identity provider involved, the user will login with a username and password to the local Azure B2C directory, and Azure B2C will return an access token and a refresh token to the mobile app. The mobile app will use the access token to access the backend API. When the access token expires, the app will submit the refresh token to Azure B2C to obtain a new access token and new refresh token. This much I understand.
Now, when we add an external identity provider, the mobile app redirects the user to Azure B2C, and then the user is redirected to the external IDP where they authenticate. A token is submitted back to Azure B2C authenticating the user, and Azure B2C issues an access token and refresh token to the mobile app. When the access token expires, the mobile app will submit the refresh token back to Azure B2C to obtain a new access token.
Now, I have the following questions:
Does Azure B2C connect back to the external IDP to verify the account status has not changed? If the account is disabled at the external customer's IDP, then Azure B2C should not issue a new access token.
If the external IDP (and underlying directory) has an update, such as to email address, or name of the user, how is that information going to be reflected in the refreshed token issued to the mobile app?
If Azure B2C does reach back out to the external IDP each time the B2C token is refreshed, what protocol does B2C use? Does it use OAuth and maintain it's own refresh token to the external IDP? Or, does it use Open ID Connect, and reinitiate the initial login process every time with the external IDP? If the latter, and there is no valid cookie or valid session at the external IDP, the user will have to go through a login or SSO flow on their external IDP again.
Ideally, I would like to have the external IDP dictate the lifetime of access tokens and refresh tokens by copying these claims from the external token to the Azure B2C issued token. I would like Azure B2C to make a roundtrip back to the external IDP each time the B2C token is refreshed, in order to insure the access is still valid, and that if any of the user's information changed it is reflected downstream in our apps. I also want the user of the mobile app to only have to login the one time (using refresh tokens), until the user's external IDP dictates that the token is no longer valid. Is this possible?
No. You would have to do this via Graph API.
In general, to get the claims updated you have to logout and login. However, it seems there's a fix for this on the way for B2C. See this. I doubt if this handles external IDP.
Related
I'm having trouble understanding how the Principal information is sent in the authentication request to the IDP (e.g. Azure AD) during the SSO authentication process.
I checked the AuthnRequest example shown in this Azure AD article, but it doesn't contain any information about the user that needs to be authenticated:
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
If the user information are not included in the authentication request, can anyone explain to me how the IDP will identify the user in this case?
The AuthnRequest is a browser redirect to the Azure IdP. The Azure IdP doesn't know who the user is either. So it displays an Azure login screen in the browser. The user then logs in to Azure (now Azure knows who the user is) and the Azure IdP redirects the browser to the AssertionConsumerService (ACS) URL of the SP with the SAML AuthnResponse from the IdP identifying the user.
The next time the user's browser is redirected to the Azure IdP by an AuthnRequest, Azure looks at the cookies and knows the user has already authenticated and immediately redirects the browser back to the ACS with the SAML AuthnResponse.
The AttributeStatement in the AuthnResponse identifies the user if the IdP has agreed to release personally identifying information about the user to that SP.
Of course, if the user does not have an account in Azure they cannot login. Azure will know who they are from their login information, which is usually their userPrincipalName, which looks like username#example.com.
As the comment suggests, the username can be in the AuthnRequest but this is not often used. The SP should not ask for the username as the username "belongs" to the user (although ultimately it "belongs" to the IdP) and the IdP may not be willing to release that information to the SP. If the SP doesn't need to know who the user is, just that they have permission to access the service, then username is irrelevant. Permissions are often granted based on the Attribute set in the AttributeStatement and this can be done without the SP ever needing to know the username of the user.
If the SP supports personalisation, such as preferences for a user, not knowing the username isn't an issue. A SAML attribute such as eduPersonTargetedID can be released by the IdP that has the same value for that combination of IdP/SP (to stop cross-service tracking) and the SP can use that to store preferences for the user without ever needing to know the username.
A common way of using SAML is to replace a username/password login screen with the SAML flow:
user goes to https://app.com
app sees the user isn't authenticated (no cookie, session or whatever). This is when a non SAML app displays a login screen.
app redirects user to their IdP. Easy in the case of a single IdP. app does not use Subject in AuthnRequest.
user's IdP displays the login screen for the IdP.
user authenticates at IdP
IdP redirects browser to the app's ACS URL.
app inspects SAMLResponse, looks at the Attribute set and decides whether the user (still possibly anonymous) can get access.
if, e.g. user has an Attribute "eduPersonEntitlement" with a value "http://app.com/entitled" then app creates a session for the user and "logs them in" to app.
when user's session at app expires, app sends them back to their IdP to see if they are still entitled to access the app.
In azure ad portal, after registering the application through enterprise application blade,we assign users and groups for the application .
we can perform single sign on configuration settings where we give
redirect urls , upload saml certificate.
SAML tokens contains information about the user known as claims. A
claim is information that an identity provider states about a user
inside the token they issue for that user. In SAML token, this data
is prsented in \ SAML Attribute Statement.
By default, the Microsoft identity platform issues a SAML token to
your app that contains a NameIdentifier claim having value of the
username ( user principal name) in Azure AD, which can uniquely
identify the user. The SAML token also can contain additional claims
like user’s email address, first name, and last name which can be
configured in a section Attributes and claims , which are included in
token .We can edit this section according to the claims required for
the application about user principal.
References:
SAML 2.0 token claims reference | Microsoft Docs
azure active-directory-saml-claims-customization(github.com)
sample reference:SAML_Token_Configuration
When using ADB2C for authentication in a Blazor Webassembly project, the authentication/logout seems to log out and shows a page with the request to close all browsers.
Anyway if the user just uses the back button in the browser she/he is still able to access the contents and is treated as still loged-on.
So, how to get a real logout?
While directing the user to the end_session_endpoint will clear some of the user's single sign-on state with Azure AD B2C, it will not sign the user out of the user's social identity provider (IDP) session. If the user selects the same IDP during a subsequent sign-in, they will be reauthenticated, without entering their credentials. If a user wants to sign out of your B2C application, it does not necessarily mean they want to sign out of their Facebook account entirely. However, in the case of local accounts, the user's session will be ended properly.
To sign out the user, redirect the user to the end_session endpoint that is listed in the OpenID Connect metadata document(example) :
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Reference: Azure Active Directory B2C: Web sign-in with OpenID Connect
How can I login a demo user with azure B2C through a API without using username and password?
I like to give visitors access to a demo account without having to sign up.
Basically my first idea is to provide a azure function or app service which returns a valid user token and/or forwards user to the app with the signed in guest user.
My app uses azure b2c oauth taking the token from url after redirect back to the app, thus it should be easy to provide the token from a second source.
I thought it should be possible to generate a valid user token through a API? Thus the API itself runs under a service user, having the right to generate the token (eg. impersonation).
What's the right approach / B2C APIs to generate this token?
There is no API to access the /authorize or /token endpoint.
Why not just create a dummy user and give people the name and password?
Or a page that kicks off the resource owner password flow with canned credentials.
I am very new to Azure B2C and trying to explore the options available to manage the identities in B2C. I have registered web application and also created required custom policy in B2C tenant. When I am trying to run the workflow from Azure B2C portal, I am able to redirect to registered application with IdToken and also able to view the ID token information in https://jwt.io
Below are some of the question which requires clarification
Suppose I have hyperlink in my web application(Asp.Net web form) which redirects the user into Azure B2C. On successful signin in Azure B2C, how to validate ,process ID Token and fetch the user information in web application. I have seen code samples related to button click event.
How to refresh the token in the above case.
The easiest way is to use the MSAL library on the client side.
This does all this for you.
You get back an id_token and an access token.
Only an access token can be refreshed.
This question is related to
passport-azure-ad, does it parse & validate token?
I've tried to master using the passport-azure-ad module. I successfully log in my user with OpenID Connect, pick up the access_token and use it directly my REST API's which are secured by app.get('myapi',passport.authenticate('oath-bearer',
{failureRedirect: '/'}),
function(req,res){});
However, if i try to log out from the session created by OpenID connect, the token is still valid untill it expires (typically 3600 seconds).
I'm using the access_token to secure my endpoint not hosted behind a API Gateway at Microsoft, so i guess revocation of the access_token is not straight forward.
Is there any way i can check if the access_token is revoked using passport-azure-ad ? What is the best practise?
According the description on Azure Document:
While directing the user to the end_session_endpoint will clear some of the user's single sign-on state with Azure AD B2C, it will not sign the user out of the user's social identity provider (IDP) session. If the user selects the same IDP during a subsequent sign-in, they will be reauthenticated, without entering their credentials. If a user wants to sign out of your B2C application, it does not necessarily mean they want to sign out of their Facebook account entirely. However, in the case of local accounts, the user's session will be ended properly.
So you can directly use the end_session_endpoint. You can find it in the metadata document for the b2c_1_sign_in policy endpoint, e.g.:
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in
As if you are using a common Azure AD application in v1, you also can find the end_session_endpoint in the metadata document at, e.g.:
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/.well-known/openid-configuration
You can refer to Azure Active Directory B2C: Web sign-in with OpenID Connect for more info.
Any further concern, please feel free to let me know.