I am trying to set up an app with a react front end + a .NET Core back end in Azure with Azure AD Auth. The back end will call other APIs and hold some logic. I set up the .NET Core app and hosted it in an Azure app service, then added authentication using the connected services wizard in visual studio, which generated code similar to what is on this tutorial (back end section):
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(sharedOptions =>
{
sharedOptions.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddAzureAdBearer(options => Configuration.Bind("AzureAd", options));
...
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseAuthentication();
...
}
appsettings.json (fake IDs):
"AzureAd": {
"ClientId": "1fff1098-3bc0-40d9-8cd0-e47b065085b6",
"Domain": "mytenant.onmicrosoft.com",
"Instance": "https://login.microsoftonline.com/",
"TenantId": "mytenantid",
"AppIDURL": "https://my-api.azurewebsites.net/",
"ConfigView": "API"
}
Then I set up react-adal on my front end with:
{
tenant: "mytenant.onmicrosoft.com",
clientId: "1fff1098-3bc0-40d9-8cd0-e47b065085b6",
endpoints: {
api: "1fff1098-3bc0-40d9-8cd0-e47b065085b6"
},
cacheLocation: "localStorage"
};
Which I set up according to the github instructions to set up react-adal. The sign in works as expected but when I run adalApiFetch against my back end, I get a 401 error with description = the signature is invalid. I can see on the debugger that the authorization header (Bearer + token) is sent. Any ideas on what I might be doing wrong here? Thanks in advance!
The endpoint I'm testing with is a simple test controller (with [Authorize]) that simply returns "Authentication Tested".
I was able to find my mistake after a while and came back to post the solution. The problem was that I was using the incorrect method/settings (not matching). From the question's code: If using sharedOptions.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; then you should also use AddJwtBearer with the appropriate configuration options (found here: JwtBearerOptions) and not AddAzureAdBearer. In my case, the final corrected startup code was
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(AzureADDefaults.BearerAuthenticationScheme)
.AddAzureADBearer(options => Configuration.Bind("AzureAd",options));
....
With corresponding settings (found here: AzureADOptions)
Related
i am playing around with Blazor WASM and IdentityServer4. Login/Logut flows invoked from the client are all working well. Used Microsofts documentation found here Microsofts Docs
IdentityServer4 is hosted as a seperate Microservice as well as the Blazor WASM App - two indepented projects.
Now i am facing the problem of signing out from the IdentiyServer4. Invoking the logout from the IdentityServer4 UI doesnt logout the user from the Blazor WASM App. I already read this explenation signout IdentityServer4
"oidc": {
"Authority": "http://localhost:8010/",
"ClientId": "demoportal.blazor",
"DefaultScopes": [
"openid",
"profile"
],
"PostLogoutRedirectUri": "http://localhost:8070/authentication/logout-callback",
"RedirectUri": "http://localhost:8070/authentication/login-callback",
"ResponseType": "code"
}
I haven´t found anything so far to achieve the goal. From my unterstanding it has to be used as oidc connect session managements not front or backend channel policy. But i cant find any useful docs on microsofts site.
After lots of reading ive found the answer.
Microsoft descripes the SPA difficulties right here: Microsoft Handle-Token-Request-Errors
These pointed me to implement on my base component something like this:
protected override async Task OnInitializedAsync()
{
await base.OnInitializedAsync();
var user = (await authenticationStateTask).User;
if (user.Identity.IsAuthenticated)
{
var tokenResult = await AccessTokenProvider.RequestAccessToken();
if(tokenResult.Status == AccessTokenResultStatus.RequiresRedirect)
{
NavigationManager.NavigateTo(tokenResult.RedirectUrl);
}
}
}
It works like a charm.
Btw dont forget to include the token when configuring HttpClient.
services.AddHttpClient<YOURSERVICEHERE>()
.AddHttpMessageHandler(sp =>
{
var handler = sp.GetService<AuthorizationMessageHandler>()
.ConfigureHandler(
authorizedUrls: new[] { "URI here" },
scopes: new[] { "your scope here" });
return handler;
})
.AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>()
I am trying to set up a web app and web API using Azure B2C as the auth mechanism, but apparently failing miserably. My web app and API are both registered in Azure, the return URIs set properly, a scope created for the API which is then granted to the app, an app client secret created, and I have tested this locally WITH IT WORKING, but now that I've published my API to my live Azure App Service, it goes wrong for some reason.
Locally, I have run my web API and web app separately, signed into the web app and then obtained an access token, called the API (running locally) and all works well. However, now the API is published and running live (i.e. https://api.myapp.net), I am running the web app locally, calling the live API and every single time I request an access token then send it to the API I get a 401 Unauthorized because apparently the signature is invalid. WHY?!?!?!?
Below are slightly redacted copies of my startup and app settings files. Note I also have Azure Front Door set up to redirect "login.myapp.net" to "myapp.b2clogin.com", this has been tested with both the user flows on the Azure dashboard and with my own app running locally and all is fine.
Here is my web app's Startup.cs file:
services.AddRazorPages();
services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(Configuration.GetSection(Constants.AzureAdB2C))
.EnableTokenAcquisitionToCallDownstreamApi(new string[] { "https://myapp.net/api/query" })
.AddInMemoryTokenCaches();
services
.AddControllersWithViews()
.AddMicrosoftIdentityUI();
services
.AddServerSideBlazor()
.AddMicrosoftIdentityConsentHandler();
services.AddAuthorization(authorizationOptions =>
{
authorizationOptions.AddPolicy(
App.Policies.CanManageUsers,
App.Policies.CanManageUsersPolicy());
});
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.ResponseType = "code";
options.SaveTokens = true;
}).AddInMemoryTokenCaches();
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
services.AddSingleton<AppData>();
services.AddScoped<IAuthTokensService, AuthTokensService>();
services.AddOptions();
My web app's appsettings.json file:
"AzureAdB2C": {
"Instance": "https://login.myapp.net",
"ClientId": "my-web-app-client-id",
"CallbackPath": "/signin-oidc",
"Domain": "my-b2c-tenant-id",
"SignedOutCallbackPath": "/signout/B2C_1_SignUpIn",
"SignUpSignInPolicyId": "B2C_1_SignUpIn",
"ResetPasswordPolicyId": "B2C_1_PasswordReset",
"EditProfilePolicyId": "B2C_1_ProfileEdit",
"ClientSecret": "my-client-secret"
},
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"AllowedHosts": "*"
Calling for an access token in my web app:
private readonly ITokenAcquisition _tokenAcquisition;
public AuthTokensService(ITokenAcquisition tokenAcquisition)
{
_tokenAcquisition = tokenAcquisition;
}
/// <inheritdoc />
public async Task<string> GetToken()
{
return await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { "https://myapp.net/api/query" });
}
My web API's Startup.cs file:
if (Configuration.GetConnectionString("SQLConnection") == null)
{
throw new InvalidOperationException("ConfigureServices: Connection string 'SQLConnection' returned null.");
}
services.AddDbContext<MyAppDbContext>(
option => option.UseSqlServer(Configuration.GetConnectionString("SQLConnection")));
services.AddMicrosoftIdentityWebApiAuthentication(Configuration, Constants.AzureAdB2C);
services.AddControllers();
services.AddScoped<IMyRepository, MyRepository>();
And my web API's appsettings.json file:
"AzureAdB2C": {
"Instance": "https://login.myapp.net",
"ClientId": "my-web-api-client-id",
"Domain": "my-b2c-tenant-id",
"SignUpSignInPolicyId": "B2C_1_SignUpIn",
"SignedOutCallbackPath": "/signout/B2C_1_SignUpIn"
},
"ConnectionStrings": {
"SQLConnection": "Server=(localdb)\\mssqllocaldb;Database=MyAppDebug;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"Logging": {
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
}
Can anybody advise on why this is? The only sensible answer I've seen anywhere online is that Blazor uses a v1.0 endpoint to obtain public keys whereas v2.0 is required for the API (see here) and I can see this happening with my tokens, but when I followed the fix given on the Microsoft documentation, I then get an exception thrown on startup of my web app IDX20807: Unable to retrieve document from: 'System.String'.
Had a C# LoB test app authenticating and authorising nicely using Azure AD with a reply url of /signing-oidc
Suddenly it's stopped validating, and the dreaded AADSTS50011 url error comes up.
I can't figure out why this has changed?
Using Microsoft.Identity.Web with the following startup.cs ConfigureServices and Configure methods:
public void ConfigureServices(IServiceCollection services) {
services.AddMicrosoftIdentityWebAppAuthentication(Configuration);
//.EnableTokenAcquisitionToCallDownstreamApi();
services.AddControllersWithViews(options => {
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
});
services.AddRazorPages().AddMvcOptions(options => {
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
}).AddMicrosoftIdentityUI();
services.AddServerSideBlazor(o => o.DetailedErrors = true);
services.AddScoped<IGpsDataService, GpsDataService>();
services.AddTelerikBlazor();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
if (env.IsDevelopment()) {
app.UseDeveloperExceptionPage();
}
else {
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints => {
endpoints.MapDefaultControllerRoute();
endpoints.MapControllers();
endpoints.MapBlazorHub();
endpoints.MapFallbackToPage("/_Host");
});
}
Pretty much boilerplate.
Can anyone point me to the correct callback url? I have it as /signin-oidc and that's configured in the appsettings.json file and on the Azure AD app authentication settings.
Stumped. Runs fine on localhost, but not in Azure 🤷♂️
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
I have a WPF client which connects successfully to a Hub, but I cannot pass the user of the client to the Hub.
My connection.User?.Identity?.Name in my class implementing from IUserIdProvider returns null.
For my WPF client I use this to connect against the Hub:
_connection = new HubConnectionBuilder()
.WithUrl(viewModel.Endpoint, opts =>
{
opts.Credentials = new NetworkCredential("user", "password", "domain");
opts.UseDefaultCredentials = true;
})
.Build();
I have then the following provider registered as singleton:
public class NameUserIdProvider : IUserIdProvider
{
public string GetUserId(HubConnectionContext connection)
{
return connection.User?.Identity?.Name;
}
}
As I mentioned above, the connection.User?.Identity?.Name; is returning null.
I don't know what else I can do to pass the user name from my client (WPF) to my Hub.
By the way, my Startup.cs looks like this:
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
services.AddLogging();
services.AddSingleton<IUserIdProvider, NameUserIdProvider>();
services.AddSignalR(hubOptions =>
{
hubOptions.EnableDetailedErrors = true;
});
services.AddScoped<IBuildsService, BuildsService>();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
endpoints.MapHub<SyncCodeHub>("/signalr");
});
}
Any help would be much appreciated.
EDIT:
I update the code with:
services.AddAuthentication(IISDefaults.AuthenticationScheme);
But the problem continues, the identity user (IUserIdProvider) is returning null when called from the WPF client. I'm running the API locally with IISExpress.
EDIT:
From Microsoft docs:
Windows Authentication is only supported by the browser client when using Microsoft Internet Explorer or Microsoft Edge.
So I'm wondering if this is even possible with an Desktop as a client. I assume it should work, so I'm wondering if I'm still missing a point or if this is a bug related to the Version of SignalR I#m using (3.1.3)
You need to configure your ASP.NET Core app to use Windows authentication by calling AddAuthentication in the ConfigureServices method of the Startup class:
services.AddAuthentication(IISDefaults.AuthenticationScheme);
You should also edit your launchSettings.json file according to the docs:
"iisSettings": {
"windowsAuthentication": true,
"anonymousAuthentication": false,
"iisExpress": {
"applicationUrl": "http://localhost:52171/",
"sslPort": 44308
}
}
I have an Identity Server using identityserver4 framework, its url is http://localhost:9000
My web application is asp.net core 2.0, its url is http://localhost:60002. This application will use the login page of Identity Server.
I want after logging in, the Identity Server will redirect to the application page (http://localhost:60002)
Here is the Startup.cs of client application
Startup.cs
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
private string AuthorityUri => Configuration.GetValue<string>("UserManagement-Authority");
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.Authority = AuthorityUri; // "http://localhost:9000"
options.RequireHttpsMetadata = false;
options.ClientId = "customer.api";
options.ClientSecret = "testsecret";
options.ResponseType = "code id_token";
options.Scope.Add("customerprivatelinesvn.api");
options.Scope.Add("offline_access");
options.GetClaimsFromUserInfoEndpoint = true;
options.SaveTokens = true;
});
services.AddMvc();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
{
HotModuleReplacement = true
});
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
routes.MapSpaFallbackRoute(
name: "spa-fallback",
defaults: new { controller = "Home", action = "Index" });
});
}
}
Here is the loggin page on Identity Server
But there is an infinite loop that calls to http://localhost:9000/connect/authorize endpoint, and then it returns to http://localhost:60002/signin-oidc with "Bad Request - Request Too Long" as below.
When I look at the cookies, there ar lots of items ".AspNetCore.Correlation.OpenIdConnect.xxx"
Here is the log on Identiy Server. It said that Identiy.Application was successfully authenticated.
Does anyone know what this problem is? And how to resolve this? Thank you very much.
Best regards,
Kevin
I also had a login loop after copying the startup code from an existing .NET Core 2.2 project and reused it in a new .NET Core 3.1 project.
The problem here was, that the app.UseAuthentication() must be called before the new app.UseAuthorization();
https://learn.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio#migrate-startupconfigure
Only in case someone is running into this issue too...
Adding default Identity in the client app would cause an infinite redirect loop.
In the client app, if you need to use UserManager, RoleManager.
Then use the below code.
services.AddIdentityCore<IdentityUser>()
.AddRoles<IdentityRole>()
.AddRoleManager<RoleManager<IdentityRole>>()
.AddSignInManager<SignInManager<IdentityUser>>()
.AddEntityFrameworkStores<ApplicationDbContext>();
In your client app, in Startup check if you have something like
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
Remove that part and try again.
In my case, I was missing RedirectUri when initiating the Signin from the client. Problem solved by adding the RedirectUri as below.
public IActionResult SignIn()
{
return Challenge(new AuthenticationProperties() { RedirectUri = "/" }, "oidc" );
}
Well, you do have a very long request shown there in your Identity Server log - and the error says "Bad Request - request too long". I'd guess that the problem is that your request is too big :)
maximum length of HTTP GET request?
Have you tried posting rather than using a GET?
This issue was solved after I updated the latest nuget package of IdentityServer4 and .NET Core.