I have configured a client in my identity server to require consent.
When logging in, the consent page is shown and the user can accept or reject it.
When accepting, the result is saved to the PersistedGrantStore [dbo].[PersistedGrants] where I verified, that the row with type user_consent is present.
Still, the next time the user logs in, the consent page is shown again... why is that?
Do I have to do something in addition so that the consent page is only shown once (if accepted)?
Thanks in advance
You can try to control the prompt parameter:
AddOpenIdConnect(options =>
{
options.Prompt = "consent";
...
}
For the possible values, see the specification here.
Then you can also configure the consent settings in the backend here:
https://docs.duendesoftware.com/identityserver/v6/reference/models/client/
Here you have the following settings:
RequireConsent
Specifies whether a consent screen is required. Defaults to false.
AllowRememberConsent
Specifies whether user can choose to store consent decisions. Defaults to true.
ConsentLifetime
Lifetime of a user consent in seconds. Defaults to null (no expiration).
Related
The disturbing scenario is: users log out of the application but their session remains valid such that they are able to sign back in without reauthenticating. Is the below code snippet the portion of the code that needs to be configured for the B2C session behaviour?
app.UseRewriter(
new RewriteOptions().Add(
context =>
{
if (context.HttpContext.Request.Path == "/MicrosoftIdentity/Account/SignedOut")
{ context.HttpContext.Response.Redirect("/Home/Index"); }
}));
When you want to sign the user out of the application, it isn't enough
to clear the application's cookies or otherwise end the session with
the user. Redirect the user to Azure AD B2C to sign out. If you fail
to do so, the user might be able to reauthenticate to your application
without entering their credentials again
The logout endpoint can receive an optional post_logout_redirect_uri parameter in the query string, where you can specify another URL where your user will be finally redirected by B2C. That can be the address of any resource, e.g. you homepage or your own page showing a "You successfully logged out of our service" message to the user.
post_logout_redirect_uri - The URL that the user should be redirected to after successful sign out. If it isn't included, Azure AD B2C shows the user a generic message.
For more details refer this document And also check with this SO Thread
When someone goes to link their social media account to their ADB2C registration, we have a problem whereby we are unable to distinguish between a failed ADB2C sign in, and the cancellation of their request to link their social media account.
When someone, for example, tries to link their Facebook account, a URL like this sits behind the 'Not now' link:
https://test.b2clogin.com/test.onmicrosoft.com/oauth2/authresp?error=access_denied&error_code=200&error_description=Permissions+error&error_reason=user_denied&state=StateProperties%3DeyJTSUQiOiJ4LW1zLWNwaW0tcmM6NzMyYWQzZWXtZGI4OS00YjZiLTlmYzgtYTY5NzYxZDdjMDY0IiwiVElEIjoiNTcxZWE5M2UtODQ4NS00MTMzLTlhZmItOTQwMWIyMDAwOGE5IiwiVE9JRCI6Ijc4ZDUxNTY3LTkzYTAtNDEyMy1iMHI1LTVmN2E1NzNjMzRkYSJ9#_=_
We trap the AuthenticationFailedNotification, but within it, we haven't been able to find a way to distinguish between
an access denied message based on the cancellation of the request to link a social media account, and
an actual genuine access denied response.
We check:
if (notification.ProtocolMessage.Error == "access_denied" && notification.ProtocolMessage.ErrorDescription.StartsWith("[A SPECIFIC ERROR ID]", StringComparison.InvariantCultureIgnoreCase))
We would then have a specific user flow configured for each scenario, based on the error description, authentication policy and authentication type (social media or ADB2C).
Our requirement is for the user to remain logged in to ADB2C when they attempt to link a social account, but don't actually go through with it.
Microsoft's own example, https://woodgrovedemo.com/ works in the same way, whereby the user is logged out when they cancel the linking of their social media account (for example, by clicking 'Not now' when going to link their Facebook account).
You can't, because it's the same thing!
When a user cancel the Facebook process with the 'Not now' button, the user ain't logged in. You need the user to accept to be link to your app for Facebook to send an approbation and a claims to be delivered to your app. Without this claims, the user is not logged in.
So you can't have a requirement to keep the user logged in, since he haven't been logged in yet. It's false to think that the Microsoft's example logged out the user, since he was never logged in.
I am using MS Graph in a desktop application so I am hosting a web browser in a form for the user to do their initial login. This all works fine and I can fully use MS Graph.
The problem I have is if we need to use an account of a different user there does not seem to be a way to reset the login. If you try to login again with the hosted web browser it will go right through and allow the same user.
The only way to reset it for another user seems to be to go into IE and delete the history/cache. Then the login screen will ask a user to login again. It seems a bit extreme to reset the cache.
So is this the only way to do this or is there something I can change in the MS Graph API call to tell it to reset?
You can force re-authentication by added prompt=login to the sign-in request:
Prompt (optional)
Indicates the type of user interaction that is required. The only valid values at this time are login, none, select_account, and consent.
prompt=login will force the user to enter their credentials on that request, negating single-sign on.
prompt=none is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform endpoint will return an error.
prompt=select_account sends the user to an account picker where all of the accounts remembered in the session will appear.
prompt=consent will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.
I have created sign in policy in my azure active directory B2C tenant and trying to retain user credentials. On my login screen there is one checkbox "Keep me sign in" which is not working. Even if I check keep me sign in checkbox, I am not able to retain user password on IE, Firefox browser. However this is working for Chrome only because it retain user credentials by default.
Please suggest me how can we overcome this problem. Can we retain user credentials on AADB2C sign in page?
I have created new signin policy in azure ad b2c and use this policy for sign in page. Sign in policy has "keep me signed in" functionality by default. We dont need to write any code. Browser will take care of session management. Whenever we mark"keep me signed in" checkbox check, browser stores user credentials on browser and we do not need to re-enter password again. It will redirect to our page.
Thank You,
We're working on a SAAS application that has recently been configured to use Azure ADAL for authentication. If it matters, we're going the oauth2 route, with response_type: code.
However, when we're testing the application, if the browser has been signed into an Azure account that does not belong to the tenant acting as identity provider, the prompt for password is bypassed, and the login fails on the Azure screen, saying AADSTS50020 - user not found in tenant.
On the one hand, congratulations to Azure for finding an already signed in user! On the other hand, there is no recourse to elect to not use this signed in user; it does not give the user the chance to interject with credentials that work.
How can we prevent this?
The core issue is we don't want users, visiting our site and ready to sign in, to have to have already signed out of Azure before trying to log in with our site.
Thanks in advance.
Please refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
You could find when requesting an authorization code during code flow , there is a Parameter :prompt indicates the type of user interaction that is required .
Valid values are:
login: The user should be prompted to reauthenticate.
select_account: The user is prompted to select an account, interrupting single sign on. The user may select an existing signed-in account, enter their credentials for a remembered account, or choose to use a different account altogether.
consent: User consent has been granted, but needs to be updated. The user should be prompted to consent.
admin_consent: An administrator should be prompted to consent on behalf of all users in their organization
You could use prompt=login forces the user to enter their credentials on that request, negating single-sign on