is there any way (OIDC auth request parameter) that I could use to prevent AAD from doing account discovery when I send the user to my AAD tenant (not /common)? Currently, AAD displays a page asking for the user email (I presume in case the user is a B2B user in my directory) and only then sends the user to my ADFS (my federation service). I would like to be able to have the user only see ADFS.
#juunas' suggestion to use domain_hint= parameter and #Rohit's to remove login= parameter did the trick. Thanks!
Related
In a browser, I can open my personal gmail account or I can open any delegated accounts by clicking the circle with my initial in and picking from the available delegates - no problem.
Via API however, I can get an access token for my personal account and use this to send mail from my own account. If I try to send from the delegated account then I get the error.
So I have a token for my personal account eg me#gmail.com
and post to https://gmail.googleapis.com/gmail/v1/users/**delegator#gmail.com**/drafts
because me#gmail.com has been delegated to by delagator#gmail.com I would expect the api call to work with my access token - in the same way as when I am signed in to my account in a browser then I can then open the delegator account without having to provide credentials again.
'{"error":{"code":403,"message":"Delegation denied for me#gmail.com","errors":[{"message":"Delegation denied for me#gmail.com","domain":"global","reason":"forbidden"}],"status":"PERMISSION_DENIED"}}'
Thanks for any help.
I think you are using a specific email address in the request. Maybe try by with userId="me".
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
I can create an invitation for a B2B user by a POST to
https://graph.microsoft.com/v1.0/invitations
and with body
{
"invitedUserEmailAddress": "yyy#test.com",
"inviteRedirectUrl": "https://myapp.com"
}
This redirects the user to "https://myapp.com" after they have redeemed their invitation.
Is is possible to invite someone without redirecting them after redemption?
If it's not absolutely necessary, I would like to avoid the hassle of hosting a confirmation webpage just for that purpose. However, the API does not accept a null or empty or relative URL for "inviteRedirectUrl".
No, there is not. The RedirectURL field is mandatory. You can, however, redirect to all kinds of URL's. So you could redirect to a generic page for your company, or google.com, or ...
inviteRedirectUrl (String) The URL user should be redirected to once the invitation is redeemed. Required.
More information: microsoft-graph-docs/api-reference/v1.0/api/invitation_post.md
And another one: HowTo: invite AAD user with Microsoft Graph
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
I'm a Salesforce system administrator and I would like to use the Web Services API on behalf of (ie: impersonate) a Salesforce user that is part of my company.
More precisely, I'm looking for a feature similar to what Google Docs already provides: https://developers.google.com/google-apps/documents-list/#using_google_apps_administrative_access_to_impersonate_other_domain_users
Can this be done ?
Thanks !
The only way to do this is to authenticate with the API using the other user's credentials. This is a security feature that cannot be avoided.
This is should be possible if you have login access for that user and a tool to inspect a browser cookies.
When you're logged in as the test user open a cookie browser and grab the value in the "sid" cookie. This is a session id for that user and can be set in the headers of an api request instead of doing a login call.
I've haven't tried this. It's possible that this session id may only be valid for the browser and not the API. In that case you should probably just create a test user with the same profile and your email. If all else fails just ask the user to temporarily change their password and share it with you.