I have a small web application to build on ASP.NET Core and it has both an UI and an API for external consumption.
I have some restrictions in terms of infrastruture so this would be hosted as a single app service in Azure if possible.
The thing is that the UI part must authenticate to an authentication provider with SAML, and the API part must authenticate/authorize with bearer tokens from Identity server.
My question is if this is possible under the same service, or if it is really necessary to have one project to the UI and other to the API?
ASP.NET Core supports multiple authentication handlers within the one application. The handlers are added through the builder.Services.AddAuthentication method.
If you're using IdentityServer4, it doesn't include native support for SAML SSO so you'll need to use something like the ComponentSpace SAML authentication handler. The following code adds support for SAML into IdentityServer4.
// Add SAML SSO services.
builder.Services.AddSaml(builder.Configuration.GetSection("SAML"));
// Add SAML authentication services.
builder.Services.AddAuthentication().AddSaml(options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.SignOutScheme= IdentityServerConstants.ExternalCookieAuthenticationScheme;
});
IdentityServer4 will delegate the SAML SSO to the SAML authentication handler which in turn will SSO to some external identity provider. IdentityServer4 will handle the issuance of bearer tokens.
This assumes that authentication has been delegated to IdentityServer4. Alternatively, you could handle the SAML SSO from within your application but it would be more involved to then have IdentityServer4 handle the issuance of bearer tokens.
Related
I'm trying to configure authentication and authorization middleware in an asp.net core 3.1 API project to be able to authorize users from:
on-premise IdentityServer4 (IDS) and
AD managed in Azure (AAD).
I'm planning to use JWT bearer tokens in both cases to call the API endpoints.
The IDS users are authenticated in a mobile app against the IDS.
The AAD users are authenticated in an admin SPA against the AAD.
The web api has separate public endpoints for IDS users and management endpoints for AAD users.
There are lots of working samples about how to configure web APIs for IDS and AAD separately, but not together.
Does anyone have an example with how this should be done?
Is it even possible to use different auth schemes (e.g JwtBearerDefaults.AuthenticationScheme, OpenIdConnectDefaults.AuthenticationScheme) for an incoming JWT bearer token?
Any directions will be appreciated.
You can have multiple AddOpenIdConnect schemes, one for AzureAD and one for IdentityServer and then let the user challenge one of them, like:
await HttpContext.ChallengeAsync("identityserver");
or
await HttpContext.ChallengeAsync("azuread");
JwtBearerDefaults only deals with processing incoming tokens and creating a user out of it.
But each JwtBearer API's likes to have one "authority"-server (not multiple). So you might need to to add multiple AddJwtBearer(one for each server).
Or you use IdentityServer as your main authorization provider and then login to Azure through IdentityServer. So your internal servers only needs to know about IdentityServer and its tokens.
Alright, so I'm having a hard time understanding a proper flow here for my setup.
Goal
I want to have a proper SSO flow for my SPA app that can authenticate users into an API.
Context
I have a React application that is intended to use an Okta porta that offers both SAML (preferred) and OIDC for SSO flows. I've wrapped my static sources in a web server that serves them, and that server has a middleware that checks for cookies, and if one doesn't exist, I redirect to the IDP (Okta) for login. This all works fine for now.
Currently, my API sits on that same server, which I intend on moving to a separate server to scale independently of the website. My API must also allow other machine clients (services) to call into it, so I implemented a service account flow that uses client ID and secret as the authentication measure.
In general, my intended flow looks like this:
User navigates to my website (unauthorized) -> Web Server -> Redirect to IDP -> Assertion Callback flow -> Generate JWT session cookie -> Web Application makes API call -> API Server auth middleware validates cookie / bearer token.
The problem.
The details of how the JWT access token is generated is where I'm stuck. Currently, my webserver receives the SAML assertion and generates a JWT, which is not the same JWT claims logic as the service accounts (bleh). I'm thinking of implementing an Auth service instead to centralize the token generation flows.
For the Auth Service, I've looked into OAuth2.0 and it seems like just the right approach for what I need. With that said, I can't find much information on patterns to follow for SAML assertion -> OAuth2.0. I saw an IETF draft for saml2-bearer grant-type, but it seems dead in the water. I'm also unsure about the general consensus on custom implemented OAuth2.0 grant types.
What does a proper flow look like? I have a couple of scenarios in mind:
SAML Service Provider within the same service as the Auth
Service. On lack of SSO session, my application redirects to my Auth service, which then redirects to my IDP. The IDP calls my SP (the auth server) with the assertion, the auth service generates a token, then my auth service redirects back to the webserver with a cookie placed in the response headers.
SAML SP as the webserver Since the webserver is the only system that needs to use the SSO, I could just keep the SAML flow within that process. Once my webserver receives the SAML assertion callback, my server makes a call to an endpoint service with the assertion claims, and then my auth service returns the access token in a JSON response.
Something else, like OAuth2.0 authorization code flow with PKCE for the web application. Or OIDC instead of SAML for SSO.
OIDC sounds like the right choice for you as APIs are involved. OAuth is designed to secure APIs' compared to SAML which is built for enterprise SSO.
You can integrate your SPA with Okta using OIDC. Okta provides SDK's for varies platforms to make it easier for you to do so. You can find SDKs' here:
https://developer.okta.com/code/angular/okta_angular_auth_js/
Once you get an ID token and Access token from Okta after OIDC flow, you can use the access token to access external API's. Your API resource server or the API gateway can validate the access token. Again Okta provides SDK's to verify access tokens: https://developer.okta.com/code/dotnet/jwt-validation/
I am new in asp.net core and want to implement authentication and authorization in WEB API 2 project. I am little bit confuse to use basic authentication, bearer token, JWT token or any other. please suggest more preferable
Thanks
Basic auth is as the name suggests, very basic and not very secure, it uses base64 encoding of the username and password so you must use HTTPS if you use it, but best is not to use it at all.
A bearer token is a type of token which effectively gives access to a resource to the "bearer" of the token. Both basic and bearer are used in an HTTP Authorization header.
You can have different formats of bearer tokens, one of which is JWT - JWT is the industry standard so I recommend you use it, and therefore you'll be using bearer tokens.
This article is a good starting point to look into all this in the context of asp.net core. See also this video series and this article goes into more detail about JWT validation.
Edit
To answer your questions in the comments:
OAuth is a standard for users to delegate permissions to apps or websites to access their resources, for example when you allow some web app to post on your behalf to your Facebook feed. Various tokens are used in this process and they're very often JWT. OAuth2 adds authentication via OpenID Connect.
OWIN on the other hand is a standard for web servers which decouples IIS and ASP.NET with the aim of allowing ASP.NET to run on other web servers which implement OWIN and other frameworks generally to run on OWIN compatible servers if those frameworks are OWIN compatible.
Auth0 is an identity platform which can do OAuth and allows you to use JWTs, generally it handles your identity and SSO. IdentityServer is another identity platform with some similar features.
I'd still recommend starting with the articles I linked at the top, don't worry too much about OWIN, and read more about OAuth to determine if you really need it. If you do, I'd recommend IdentityServer.
ASP.NET Core 2.0 and above Web API authentication and authorization
Bearer type JWT Token based authentication
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
Please implement as following below post
https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login
I am looking for a way to combine Windows Authentication and Identity/token based authentication. I have a Web API that currently uses OWIN to authenticate with Bearer tokens via the /token path and the ASP Membership database. The application that currently accesses this is external and will use a login form to log in.
The second administration application will be internal and I would like to utilize the same Web API RestFul service and allow windows authentication to it.
Is there a way to allow OWIN to allow both options for authentication? or do I need to do the Windows Authentication in another layer and have that layer call the WebAPI with a token?
I've created a mvc web application that uses openid to authenticate with Azure Ad and get the claims along with the token. I'm interfacing with Web Api to do the business transactions. The web Api is configured to oauth bearer tokens.
I've created separate oauth clients in Azure Ad for the Web App and Web Api. I'm able to get a token for Web Api from the Mvc Controller using AuthenticationContext to send to request to Web Api. I need to know how I can send the current User Claims as well to the Web Api. The claims in the Web Api are not having the claims of the User from the Web App.
Let me provide a bit more context here. I've created a MVC Web Application and a Web Api layer. The MVC Web App is configured to use OpenID authentication using Azure AD and I've configured the Web Api layer to authorize using OAuth Bearer tokens. The actions in the Web Api layer will be called through ajax requests and the bearer token will be added to the header of each Ajax requests. When the User is authenticated in the Web App, additional claims are added to the User on top of the claims from Azure Ad. I'm able to create a token for the Web Api layer using AuthenticationContext.AcquireToken, but the token for Web Api does not have the User info from the Web App.
I'm taking a wild stab in the dark here, based on what I think is happening.
Claims are attached the user, so theoretically, any claim you add in one place should be available in the other, as long as both applications share the same user datastore. However, claims are loaded at the point of authentication and not dynamically updated. As a result, if you're already logged in to the web application and you add a claim with your Web Api, that claim will not be available on the web application side until the user is re-authenticated.