Develop Reference

OpenId Connect and Custom Identity Framework

I'm using the Okta example for implementing OpenIdConnect in an Asp.NET 4.6.x MVC web application. The application uses Unity for Dependency Injection and one of the dependencies is a custom set of classes for the Identity Framework. I'm not using the Okta API because the IdP is not actually Okta and I'm assuming there's proprietary stuff in it. So it's all .NET standard libraries for the OpenId portions.
I can walk through the code after clicking login and it will carry me to the IdP and I can log in with my account, and then it will bring me back and I can see all of the information from them for my login. But it doesn't log me in or anything as it does in the example from Okta's GitHub.
Basically I'm wondering if the identity customization is what's interfering with the login and if there's a way to get in the middle of that and specify what I need it to do?
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions {
ClientId = clientId
, ClientSecret = clientSecret
, Authority = authority
, RedirectUri = redirectUri
, AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive
, ResponseType = OpenIdConnectResponseType.CodeIdToken
, Scope = OpenIdConnectScope.OpenIdProfile
, PostLogoutRedirectUri = postLogoutRedirectUri
, TokenValidationParameters = new TokenValidationParameters { NameClaimType = "name" }
, Notifications = new OpenIdConnectAuthenticationNotifications {
AuthorizationCodeReceived = async n =>
{
//var tokenClient = new TokenClient($"{authority}/oauth2/v1/token", clientId, clientSecret);
var tokenClient = new TokenClient($"{authority}/connect/token", clientId, clientSecret);
var tokenResponse = await tokenClient.RequestAuthorizationCodeAsync(n.Code, redirectUri);
if (tokenResponse.IsError)
{
throw new Exception(tokenResponse.Error);
}
//var userInfoClient = new UserInfoClient($"{authority}/oauth2/v1/userinfo");
var userInfoClient = new UserInfoClient($"{authority}/connect/userinfo");
var userInfoResponse = await userInfoClient.GetAsync(tokenResponse.AccessToken);
var claims = new List<System.Security.Claims.Claim>();
claims.AddRange(userInfoResponse.Claims);
claims.Add(new System.Security.Claims.Claim("id_token", tokenResponse.IdentityToken));
claims.Add(new System.Security.Claims.Claim("access_token", tokenResponse.AccessToken));
if (!string.IsNullOrEmpty(tokenResponse.RefreshToken))
{
claims.Add(new System.Security.Claims.Claim("refresh_token", tokenResponse.RefreshToken));
}
n.AuthenticationTicket.Identity.AddClaims(claims);
return;
}
, RedirectToIdentityProvider = n =>
{
// If signing out, add the id_token_hint
if (n.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
{
var idTokenClaim = n.OwinContext.Authentication.User.FindFirst("id_token");
if (idTokenClaim != null)
{
n.ProtocolMessage.IdTokenHint = idTokenClaim.Value;
}
}
return Task.CompletedTask;
}
}
});

The token(s) returned by Okta have to be managed by your application in order to perform the login action. The OIDC token returned will need to be verified and validated by you, and then a decision made as to whether to accept the OIDC token. If so, you take action to log the user into your application. Recieving an OIDC token as a result of an OpenID Connect flow doesn't by itself log you into an app. The app needs to do some more work based on the token content before taking a login or reject action.

Unable to obtain username from WebAPI in ADFS4-OAuth2 OpenID

I am trying to use ADFS Authentication with OAuth to communicate between my webapp and webapi. I am using ADFS4 and have configured application group with Server application and Webapi accordingly. I am trying to receive the userdetails, particularly the username from the webapi controller. Is it possible to pass the username details within the access token passed to webapi. Here is what I did from the Webapp side:
In the webapp controller after adfs authentication,
authContext = new AuthenticationContext(Startup.authority, false);
ClientCredential credential = new ClientCredential(Startup.clientId, Startup.appKey);
string accessToken = null;
bool isAuthenticated = User.Identity.IsAuthenticated; //return true
string username = User.Identity.Name; // returns username
string userId = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Name).Value; // returns username
HttpClient httpClient = new HttpClient();
try
{
result = authContext.AcquireTokenAsync(Startup.apiResourceId, credential).Result;
accessToken = result.AccessToken;
}
catch (AdalException ex)
{
}
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
HttpResponseMessage response = httpClient.GetAsync(Startup.apiResourceId + "/api/ConfApi").Result;
From the Webapi end, in Startup.Auth.cs, I have added these code
public void ConfigureAuth(IAppBuilder app)
{
JwtSecurityTokenHandler.InboundClaimTypeMap.Clear();
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters() {
SaveSigninToken = true,
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
}
});
}
However, within the ConfApi controller, I cannot find any claims with user details.
What can I do to receive user details in the Webapi controller?
Thanks for any help.

Are you actually receiving the claims?
Did you configure claims rules for the web API on the ADFS side?
What did you use for Name - Given-Name, Display-Name etc?
Use something like Fiddler to monitor the traffic. After the OIDC authentication, you should see access tokens, id tokens etc.
Take the token and copy into jwt.io.
This will show you what you are actually receiving.
However, the OWIN classes translate the simple OAuth attributes e.g. "aud" into the claim type URI e.g. http://claims/this-claim so breakpoint and see what is in the claims collection and what type has been assigned to each.

The answer to this is the same answer to the question: MSIS9649: Received invalid OAuth request. The 'assertion' parameter value is not a valid access token
You have to use authorization code flow (instead of client credentials grant flow) to get the server app (web app in this case) to talk to the web API with the user's context. Authorization code flow will pass the claims in the JWT Token. Just make sure you pass thru any claims you need for the web API in the web API's RPT claim issuance transform rules.
Vittorio has a nice post on authorization code flow, although it talks about azure.
In order to use authorization code flow, you need to handle the AuthorizationCodeReceived Event via Notifications on the OpenIdConnectAuthenticationOptions from Startup.ConfigureAuth(IAppBuilder app)
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions {
...
Notifications = new OpenIdConnectAuthenticationNotifications {
AuthorizationCodeReceived = async code => {
ClientCredential credential = new ClientCredential(Startup.clientId, Startup.appKey);
AuthenticationContext authContext = new AuthenticationContext(Startup.authority, false);
AuthenticationResult result = await authContext.AcquireTokenByAuthorizationCodeAsync(
code.Code,
new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)),
credential,
Startup.apiResourceId);
}
}
When you are ready to make the call you acquire your token silently.
var authContext = new AuthenticationContext(Startup.authority, false);
var credential = new ClientCredential(Startup.clientId, Startup.appKey);
var claim = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value;
var userId = new UserIdentifier(claim, UserIdentifierType.UniqueId);
result = await authContext.AcquireTokenSilentAsync(
Startup.apiResourceId,
credential,
userId);
HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
"Bearer",
result.AccessToken);

How do I collect more information from a user after authenticating externally?

I'm using the Microsoft.AspNetCore.Authentication.Google package. If I allow a user to authenticate with Google, where is the place that I should inject my own form to collect some more information that Google would not have access to (a custom identifier for example).
Should I present a form, collect the data up front and store it in session or something while they go off to authorize the login?
Should I let them go authorize the login, then when the callback URL is invoked, present the form there?
There are four events exposed via the middleware:
OnTicketReceived
OnCreatingTicket
OnRedirectToAuthorizationEndpoint
OnRemoteFailure
Is there an example anywhere that this is being done? I can't seem to find anything.

I have done it with Cookie middleware. I added 'temp' cookie middleware to catch the ClaimsPrincipal from logging in to Google and then I sign in to the 'real' Cookie middleware to persist the enriched ClaimsPrincipal. The relevant piece of code in the Configure method of the StartUp class:
app.UseCookieAuthentication(
new CookieAuthenticationOptions()
{
AuthenticationScheme = "Cookie",
AutomaticAuthenticate = true,
AutomaticChallenge = true,
LoginPath = new PathString(#"/account/login"),
AccessDeniedPath = new PathString(#"/account/accessdenied")
});
app.UseCookieAuthentication(
new CookieAuthenticationOptions()
{
AuthenticationScheme = "Temp",
AutomaticAuthenticate = false
});
var googleOptions = new GoogleOptions()
{
AuthenticationScheme = "Google",
SignInScheme = "Temp",
AppId = "yourappidhere",
AppSecret = "yourappsecrethere"
};
googleOptions.Scope.Add("scopesyouneed");
app.UseGoogleAuthentication(googleOptions);
Note how the SignInScheme of the googleOptions is "Temp" and the options of the 'temp' Cookie middleware has it's AutomaticAuthenticate to false (because you don't want to automatically persist the ClaimsPrinciple in the temp Cookie, but enriched and all in the real one which is called "Cookie" here).
Then the relevant methods in my controller look like:
public async Task<IActionResult> Register(string returnUrl = null)
{
var externalPrincipal = await HttpContext.Authentication.AuthenticateAsync("Temp");
//TODO Check external principal and retrieve claims from db or whatever needs to be done here.
var claims = new List<Claim>()
{
new Claim("email", externalPrincipal.FindFirst(ClaimTypes.Email).Value)
};
var id = new ClaimsIdentity(claims, "password");
await HttpContext.Authentication.SignInAsync("Cookie", new ClaimsPrincipal(id));
await HttpContext.Authentication.SignOutAsync("Temp");
return Redirect(returnUrl);
}
public async Task<IActionResult> LogInGoogle(string returnUrl = null)
{
var queryString = !string.IsNullOrWhiteSpace(returnUrl) ? $"?returnUrl={returnUrl}" : string.Empty;
var props = new AuthenticationProperties() { RedirectUri = $#"Account/Register{queryString}" }; //new PathString(returnUrl)
return await Task.Run<ChallengeResult>(() => new ChallengeResult("Google", props));
}
Note how LoginGoogle is called via a link on your page or something. Remember how GoogleMiddleware's SignInScheme is "Temp" at this point. It's redirected to the "Register" action method. There you extract the ClaimsPrinciple from Google with the code:
var externalPrincipal = await HttpContext.Authentication.AuthenticateAsync("Temp");
At this point you can do whatever you need to do with the claims. I extract the e-mail claim as you can see. And I sign in with my "Cookie" sign in scheme, to persist the ClaimsPrinciple in a cookie. But you could also redirect to the view with the form with which you request more information from the user.

Generate Identity from bearer token

Is there a way to take a Bearer Token string and convert it to the Identity object manually in asp.net?
Cheers,
Aziz

This is a pretty old question, but I think answer was still missing. I was able to regenerate Principal by using the following line
var ticket = Startup.OAuthOptions.AccessTokenFormat.Unprotect(accessToken);
var identity = ticket.Identity;

First you need to crate some claims based on token then create ClaimsIdentity and use it to authorize the user.
public ActionResoult Login(string token)
{
if(_tokenManager.IsValid(token))
{
// optionally you have own user manager which returns roles and user name from token
// no matter how you store users and roles
var user=_myUserManager.GetUserRoles(token);
// user is valid, going to authenticate user for my App
var ident = new ClaimsIdentity(
new[]
{
// adding following 2 claim just for supporting default antiforgery provider
new Claim(ClaimTypes.NameIdentifier, token),
new Claim("http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider", "ASP.NET Identity", "http://www.w3.org/2001/XMLSchema#string"),
// an optional claim you could omit this
new Claim(ClaimTypes.Name, user.Username),
// populate assigned user's role form your DB
// and add each one as a claim
new Claim(ClaimTypes.Role, user.Roles[0]),
new Claim(ClaimTypes.Role, user.Roles[1]),
// and so on
},
DefaultAuthenticationTypes.ApplicationCookie);
// Identity is sign in user based on claim don't matter
// how you generated it
HttpContext.GetOwinContext().Authentication.SignIn(
new AuthenticationProperties { IsPersistent = false }, ident);
// auth is succeed, just from a token
return RedirectToAction("MyAction");
}
// invalid user
ModelState.AddModelError("", "We could not authorize you :(");
return View();
}
Now you could use Authorize filter as well:
[Authorize]
public ActionResult Foo()
{
}
// since we injected user roles to Identity we could do this as well
[Authorize(Roles="admin")]
public ActionResult Foo()
{
// since we injected our authentication mechanism to Identity pipeline
// we have access current user principal by calling also
// HttpContext.User
}
Also I encourage you to have look Token Based Authentication Sample from my github repo as a very simple working example.

The token just holds claims and it's just used for authentication into the resource. If one of those claims held user information you could create an identity and assign the claims to it.
public void ValidateBearerToken(OwinContext context)
{
try
{
var tokenHandler = new JwtSecurityTokenHandler();
byte[] securityKey = GetBytes("some key"); //this should come from a config file
SecurityToken securityToken;
var validationParameters = new TokenValidationParameters()
{
ValidAudience = "http://localhost:2000",
IssuerSigningToken = new BinarySecretSecurityToken(securityKey),
ValidIssuer = "Self"
};
var auth = context.Request.Headers["Authorization"];
if (!string.IsNullOrWhiteSpace(auth) && auth.Contains("Bearer"))
{
var token = auth.Split(' ')[1];
var principal = tokenHandler.ValidateToken(token, validationParameters, out securityToken);
context.Request.User = principal;
}
}
catch (Exception ex)
{
var message = ex.Message;
}
}

ADAL JavaScript: Adding additional claims (ADAL JS)

I ran the ADAL JS sample SPA project from Github against my Azure AD.
That works well, but I want to add claims to the token after authentication.
In the SPA sample, you add middle-ware as follows:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
});
From here, do you have to add additional OAuth middleware to get access to something like Notifications to get to the ClaimsIdentity and AddClaim?

You can use the TokenValidationParamenters. See ValidateToken or TokenValidationParameters.CreateClaimsIdentity

I found a great sample that handles exactly this... the magic happens inside Provider = new OAuthBearerAuthenticationProvider.
You see that additional claims are added to identity.
// Add bearer token authentication middleware.
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
// The id of the client application that must be registered in Azure AD.
TokenValidationParameters = new TokenValidationParameters { ValidAudience = clientId },
// Our Azure AD tenant (e.g.: contoso.onmicrosoft.com).
Tenant = tenant,
Provider = new OAuthBearerAuthenticationProvider
{
// This is where the magic happens. In this handler we can perform additional
// validations against the authenticated principal or modify the principal.
OnValidateIdentity = async context =>
{
try
{
// Retrieve user JWT token from request.
var authorizationHeader = context.Request.Headers["Authorization"].First();
var userJwtToken = authorizationHeader.Substring("Bearer ".Length).Trim();
// Get current user identity from authentication ticket.
var authenticationTicket = context.Ticket;
var identity = authenticationTicket.Identity;
// Credential representing the current user. We need this to request a token
// that allows our application access to the Azure Graph API.
var userUpnClaim = identity.FindFirst(ClaimTypes.Upn);
var userName = userUpnClaim == null
? identity.FindFirst(ClaimTypes.Email).Value
: userUpnClaim.Value;
var userAssertion = new UserAssertion(
userJwtToken, "urn:ietf:params:oauth:grant-type:jwt-bearer", userName);
// Credential representing our client application in Azure AD.
var clientCredential = new ClientCredential(clientId, applicationKey);
// Get a token on behalf of the current user that lets Azure AD Graph API access
// our Azure AD tenant.
var authenticationResult = await authenticationContext.AcquireTokenAsync(
azureGraphApiUrl, clientCredential, userAssertion).ConfigureAwait(false);
// Create Graph API client and give it the acquired token.
var activeDirectoryClient = new ActiveDirectoryClient(
graphApiServiceRootUrl, () => Task.FromResult(authenticationResult.AccessToken));
// Get current user groups.
var pagedUserGroups =
await activeDirectoryClient.Me.MemberOf.ExecuteAsync().ConfigureAwait(false);
do
{
// Collect groups and add them as role claims to our current principal.
var directoryObjects = pagedUserGroups.CurrentPage.ToList();
foreach (var directoryObject in directoryObjects)
{
var group = directoryObject as Group;
if (group != null)
{
// Add ObjectId of group to current identity as role claim.
identity.AddClaim(new Claim(identity.RoleClaimType, group.ObjectId));
}
}
pagedUserGroups = await pagedUserGroups.GetNextPageAsync().ConfigureAwait(false);
} while (pagedUserGroups != null);
}
catch (Exception e)
{
throw;
}
}
}
});