Develop Reference

Sign in to ASP.Net Core Web Application -> API with Individual User Accounts using Azure AD B2C ADB2C

I have set up a Web Application with ASP.NET Razor Pages with -> Individual User Accounts -> Connect to an existing user store in the cloud (Azure AD B2C).
This works really well and I could both sign up and sign in to the web application.
However when I follow the guide for API I don't understand how to sign in.
The example Controller /weatherforecast simply returns a HTTP 401 when the web application is started.
Looking at the file structure I can't find any clues either but this could be similar to scaffolding I guess.
https://stackoverflow.com/a/50677133/3850405
If I comment out [Authorize] from WeatherForecastController I get a HTTP 200 so what I need is probably just a token from Azure AD B2C that is being sent to the Controller in the GET request.
I know that the B2C tenant and application work since I use the same application for the API as I did with the Web Application. It was set up using Microsofts own guide:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-tenant

Update 2020-07-27:
Applications are now Legacy and App registrations should be used instead. See this guide:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-register-applications?tabs=app-reg-ga#register-a-web-application
Old:
Fixed it using these guides:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview
https://learn.microsoft.com/en-us/azure/active-directory-b2c/access-tokens
I had some trouble where I got the error "AADB2C90205: This application does not have sufficient permissions against this web resource to perform the operation. numerous times. Turned out I had not declared the correct scopes for the application.
First step is therefore to make sure you have a read scope for your Azure AD B2C application under Published scopes:
Then under API access add your application with the scope read.
Then perform a GET request with this format, simplest way to test is to use it in Chrome or any other browser:
https://<tenant-name>.b2clogin.com/tfp/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=https://<tenant-name>.onmicrosoft.com/api/read
&response_type=code
Make sure the redirect_uri is present as Reply URL for your application.
This should give you a result like after logging in like https://jwt.ms/?code=... or https//localhost:44376/signin-oidc?code= depending on redirect_uri. Microsoft example uses https://jwt.ms but I prefer to keep my codes on domains that I control.
Copy the value from code parameter and then perform a POST request, I use Postman.
POST <tenant-name>.onmicrosoft.com/oauth2/v2.0/token?p=<policy-name> HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=<application-ID>
&scope=https://<tenant-name>.onmicrosoft.com/api/read
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=<app-key>
client_secret is from Keys:
Correct response should look like this:
Then you can copy the value for access_token and access your local API with Bearer Authorization. To see the content of your access_token you can copy the value to https://jwt.ms/

Web Api: How do I allow only my mobile app and website to connect? [duplicate]

A common use case for WebAPI would be to have shell views rendered by MVC controllers, which contain javascript that then hit your API to access data.
But let's say you have some expensive API operations and you don't want people remotely accessing those endpoints -- you only want your MVC views, delivered by your application, to access them. How could you go about protecting them?
In this case Request.IsLocal doesn't work, because javascript is invoking it from the client's browser on their machine. Even if it did work, you need to dig to get the real HttpContext in order to find this property -- and that solution wouldn't work in self-hosted WebAPI.
For API endpoints that require a valid IPrincipal, you could protect them with the [Authorize] attribute. But what about API endpoints that you want your app to be able to access for anonymous users?
I have tried a solution and will post it separately as an answer, because I'm not sure if it's the best (or even a good) approach.

If your MVC site uses authentication, you could enable forms authentication for your Web API methods. You could write a custom [Authorize] attribute that will check for the presence of a forms authentication cookie which will be sent from the AJAX call and if present construct the principal.
Another possible solution is to protect your API with tokens which is a more RESTful style. The idea here is that when a user authenticates on your MVC website you could generate and pass a token to the view which will be used when sending the AJAX request to the Web API which in turn will verify the validity of the token and its signature.
If on the other hand your site doesn't use authentication, then things will get very complicated because you have no way of knowing whether the request comes from a trusted client since you are using javascript to call your API methods.

Before you go harping about "what have you tried", here is what I have tried. It works. Just not sure if there is a better way.
Create an MVC action filter and add it as a global filter during Application_Start.
Create an Http (WebAPI) action filter and use it on actions that should reject remote requests.
The global MVC filter does this:
Looks for a specific cookie in the request. If the cookie is there, its value is decrypted. The decrypted value should be a string representation of a DateTime, so use DateTime.TryParse to get it out. If the value is correctly parsed to a DateTime, and that DateTime is less than a day old, STOP HERE and do nothing else.
If the cookie is not there, or cannot be decrypted / parsed, or is older than a day, write a new cookie to the browser. Use the current DateTime.UtcNow.ToString() as the value, encrypt it, and write it with HttpOnly = false.
The WebAPI filter does this:
Looks for a specific cookie in the request. If the cookie is there, decrypt its value and try to parse it out as a DateTime.
If the value is a valid DateTime and is less than 2 days old, STOP HERE and do nothing else.
Otherwise, throw a 403 Forbidden exception.
A couple of notes about my current implementation of this. First of all, I use AES encryption with a shared secret and a salt. The shared secret is stored as an appSetting in web.config. For the salt, I enabled anonymous identification and used Request.AnonymousID as the salt. I'm not entirely fond of the salt because it's tricker to get at in a WebAPI controller, but not impossible as long as it is not self-hosted.

Web API token authentication with a custom user database

I am developing a Web API 2.1 service that needs to authenticate the connecting clients (HTML5/JS clients that I will create and control). Unfortunately, the user information (username, password hashes, roles and much, much more info) is stored in an existing (SQL Server) database to which I only have read access. The Users database table was created 5-6 years ago without any reference to security frameworks, so it's a completely custom format. I'm not allowed to make any changes to either the data or the database structure.
Inspired by this article, I rolled my own token-based method of authenticating users, but I'm lacking the completeness and (re)assurance of using an established security framework.
Is there a way to integrate an existing framework, e.g. OAuth2, within my current project given the constraints I mentioned above? I don't know if it makes any difference, but I'm self-hosting using OWIN.

This is a good answer to a similar question.
It basically says:
Make a custom user class which implements IUser
Define a custom user store which implements public class UserStoreService
: IUserStore<CustomUser>, IUserPasswordStore<CustomUser>
wire everything up
Since the answer is pretty extensive I just provided the basic steps...
details are here: How to customize authentication to my own set of tables in asp.net web api 2?
This is also a very valuable content which also applies to web api:
Customizing ASP.NET Authentication with Identity by JumpStart
https://channel9.msdn.com/Series/Customizing-ASPNET-Authentication-with-Identity
HTH

Someone else, having the competence, can explain the options. But if authentication as service is an option, then check out Auth0 # https://auth0.com
I have tested the service (as Azure plugin) using both HTML/JS- and native Windows Phone applications, against simple Sql Server table and AD. Works liek charm, near zero headache.

I stumbled upon a my solution while trying to implement json token authentication within web api. It is important to note that my solution handles authentication by sending a json token through the Authentication header of the Http request (not via cookies) and not using Microsoft.Identity framework.
Anyway, I basically implemented in a cookbook fashion the solution helpfully described here by Taiseer Joudeh: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
The key thing to notice is the following bit of code:
//Dummy check here, you need to do your DB checks against memebrship system http://bit.ly/SPAAuthCode
if (context.UserName != context.Password)
{
context.SetError("invalid_grant", "The user name or password is incorrect");
//return;
return Task.FromResult<object>(null);
}
Naturally you would replace this bit of code above with your own method for checking your (presumably pre-existing) user database(s). Once I implemented this I realized that you don't need to use new code first identity framework that Visual Studio installs for you.
To make this work I did the following:
1) Created an an empty project and selected Change Authentication/Individual User Accounts. This installs most of the required references and files you need out of the box to use token authentication by way of cookies as well as the code-first identity framework files.
2) Edited these files following Taiseer Joudeh's lead. This requires
some new objects such as CustomOAuthProvider.cs among others. And you need to implement your own user/password check by customizing this code block:
if (context.UserName != context.Password)
{
context.SetError("invalid_grant", "The user name or password is incorrect");
//return;
return Task.FromResult<object>(null);
}
Link to Taiseer Joudeh's instructions: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
3) Pruned my project of extraneous files (AccountBindingModels.cs, AccountViewModels.cs, IdentityModels.cs, ApplicationOAuthProvider.cs, identityConfig.cs, AccountBindingModels.cs, AccountViewModels.cs). Basically, No more microsoft identity references.
I am sure the microsoft.identity thing is excellent, but I was annoyed with the code-first implementation of databases when I was already using some legacy databases of a different structure etc. Hope this helps. I am quite satisfied with the result (after a few days of messing around to get it to work).

I did not want to use any existing classes and finally come out some thing very simple like
var userName = context.UserName;
var password = context.Password;
var userService = new UserService(); // our created one
var user = userService.ValidateUser(userName, password);
if (user != null){
.......
}
See the full details here OAuth Web API token base authentication with custom database
For Role base authentication with custom database
Hope it will help

This might be a completely insane and invalid approach for you but I faced a similar challenge: New web app (MVVM + WebAPI), legacy system used to issue and validate tokens. Inspired by http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet, and because my application would primarily be used by its accompanied GUI (the MVVM webapp), I decided to use a "cookie based" token produced by FormsAuthentication. The FormsAutnentication cookie/ticket is secured by .net internal magic security (which I assume id completely safe and unbreakable).
In my case the cookie simply holds the ticket issued by the legacy system, (but you could store more details there as well, eg by JSONSerializing a custom type). During authorization, my system validates the token against the legacy system. I guess you could use something similar together with a custom AuthorizationFilter.

Delegating secure tokens from one relying party to another

I have a WCF service that is a relying party for a custom STS, built using WIF. My STS issues holder-of-key tokens to my client application. I have created a new 'backend' WCF service, that I need to call from the existing 'frontend' service. How can I use the incoming secure token in the frontend service to call the backend service, without retrieving a new one from the STS?
So far, in my frontend service, I have no problem accessing the incoming SamlSecurityToken using a custom Saml11SecurityTokenHandler.
After that, I tried two different ways to attach the out of band token to a service call on my target backend service:
Create a custom IssuedSecurityTokenProvider
Use ChannelFactoryOperations.CreateChannelWithIssuedToken
However, both of these attempts result in errors. From what I can tell, it seems to be the same dead end, - they do not accept the signed SamlSecurityToken. It seems that even though both of these methods accept the base SecurityToken class, they both only work if given a GenericXmlSecurityToken instance, instead of a SamlSecurityToken.
Update:
Here is a code sample and the exception details for bullet #1
Update 2:
After doing some more research, the closest thing I can find was an article about using Identity Delegation for WIF/ADFS which basically just uses ActAs tokens, in which the front end service would issue a request to the STS using the token it recieved from the client application. This would require an update to our custom STS, which we're hoping not to do at this time. I'm starting to wonder if the approach that I've illustrated in my diagram is even valid for WIF or WS-Trust?

As it turns out, the the concept of reusing an issued token by a front-end service to call a back-end service IS valid within the confines of WS-Trust protocol. However, for the vast majority of scenarios, it should not be considered a good practice. This is due to security and extensibility concerns. Security-wise, doing so would force both relying parties to use the same token encryption algorithms/keys, and also reduces your ability to authenticate the SAML token's audience restriction. This is exactly why WS-Trust was updated to support Identity Delegation with both ONBEHALFOF and ACTAS tokens. Utilizing either of these will help deal with this exact scenario in a more secure and robust way. It appears that the design of WIF's API follows this line of thinking, which explains why there is no direct API to be found for a front end service to reuse an incoming signed holder-of-key token to call a back-end service.
In conclusion, I have two answers to this question:
A. If you are the owner of your own custom-built STS, you can achieve this scenario outside of the default WIF/WCF pipeline, by following these steps:
In the client requestor application, manually retrieve the token from the STS using either WSTrustChannel or an IssuedSecurityTokenProvider. Notice that the token type will be GenericXmlSecurityToken, or some derivation of that.
Send the token, out-of-band, to the front end service. By out-of-band, I mean send it as an extra contract field, in a message header, or any other way.
Within the front end service, you can easily use the out-of-band token to call the back-end service by using ChannelFactory.CreateChannelWithIssuedToken() or by creating a custom IssuedSecurityTokenProvider. This is not possible when using an incoming bootstrap token, because WIF will always create a bootstrap token as a specific type, such as SamlSecurityToken. Both ChannelFactory and the IssueSecurityTokenProvider will only work with the GenericXmlSecurityToken!
B. Whether you have an out-of-box STS or a custom one, as long as it supports ActAs or OnBehalfOf, you can use proper Identity Delegation.
My conclusions are largely based on the following sources. I hope this ends up helping someone else with similar requirements.
http://www.cloudidentity.com/blog/2008/09/07/delegation-or-traversing-multilayer-architectures/
(Amazing explanation of ACTAS/ONBEHALFOF vs token reuse)
http://msdn.microsoft.com/en-us/library/ee748487.aspx (scroll down to find a comparison of ACTAS and BEHALFOF)
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html
(wstrust protocol, of course)

How to use OAuth accesstoken to acquire profile images from various providers using DotNetOpenAuth.AspNet and Microsoft.AspNet.Membership.OpenAuth?

I've created a web application that uses the OAuth authentication and universal connectors as explained in this tutorial, and started to fiddle around a little to add support for other providers like Yahoo and LinkedIn. So the authentication part works and users are created in the asp.net Membership provider. Also, all the providers return the accesstoken which I supposedly can use to retrieve more information regarding the user.
I'd really like to acquire the profile image, but it seems every provider has a different way of requesting this information. Twitter even describes a way to authorise every request by changing the HTTP header information.
Whilst reading this information on the websites of the various providers I was wondering whether this functionality isn't also already included somewhere in DotNetOpenAuth.AspNet or Microsoft.AspNet.Membership.OpenAuth implementation.
How can I use DotNetOpenAuth.AspNet and/or Microsoft.AspNet.Membership.OpenAuth to request the profile image of the loggedin user using the just acquired accesstoken?
UPDATE in response to Leo's answer
I use the following code to make a call on LinkedIn's API.
string accessToken = extraData["accesstoken"]; // Extra Data received from OAuth containing the accesstoken.
WebRequest request = WebRequest.Create("https://api.linkedin.com/v1/people/~:(id,first-name,last-name,date-of-birth,email-address,picture-url)?oauth2_access_token=" + accessToken);
using (WebResponse response = request.GetResponse())
{
// do something with response here.
}
Error message is "The remote server returned an error: (401) Unauthorized.".
What am I doing wrong?

The answer is simple...you can't use any of these. These are wrappers of OAuth and OAuth only specifies how you can authenticate a user. Now, to request the user's profile photo you will need to use the external provider's own API and you will need most likely a valid access token. So, you will need to use one of these implementations of OAuth to authenticate a user and the recieve an access token, store the access token somewhere (usually a cookie) and then use the access token to make sub-sequent calls to the provider's APIs. Examples and links....
Facebook's Graph API allows you to retrieve users profiles
https://developers.facebook.com/docs/graph-api/quickstart/
notice that all examples in the link above will require you to include the access token in a parameter named access_token, for example
https://graph.facebook.com/me?method=GET&format=json&suppress_http_code=1&access_token={your-access-token}
Google...
https://www.googleapis.com/oauth2/v3/userinfo?access_token={your-access-token}
LinkedIn...
https://api.linkedin.com/v1/people/~:(id,first-name,last-name,date-of-birth,email-address,picture-url)?oauth2_access_token={your-access-token}
You can get more specific information from these providers' websites
Let me know if you have any other doubts I might be able to help you since I have implemented stuff like these before.
Cheers, Leo