Authentication in AuthorizationServer

AS does not do its own authentication – that’s by design. When you download from the repo, AS is set up to be a WS-Federation relying party. In the configuration folder of the WebHost project you’ll find two config files: identity.config and identityservices.config that wire up AS to an IdP.




    <wsFederation passiveRedirectEnabled=true


                  realm=urn:authorizationserver />





You can change these settings to connect to your own IdP, e.g. IdentityServer, ADFS, ACS or WAAD. The “Identity & Access” VS plugin makes it even easier to “auto-configure” AS (just don’t forget to remove the pesky authorization elements from web.config).

AS really only needs a single claim on the current principal to function properly – sub – the subject identifier claim from the JWT spec. It’s the job of claims transformation to provide this claim after authentication has happened. For this purpose AS comes with a pre-defined claims authentication manager that turns incoming NameIdentifier or Name claims into a sub claim. That works out of the box for the above mentioned IdPs:

public class NameIdToSubjectClaimsTransformer : ClaimsTransformerBase
    public NameIdToSubjectClaimsTransformer(
        : base(svc)
    { }
    protected override Claim GetSubject(ClaimsPrincipal principal)
        var nameId = principal.FindFirst(ClaimTypes.NameIdentifier);
        if (nameId == null)
            nameId = principal.FindFirst(ClaimTypes.Name);
            if (nameId == null)
                throw new InvalidOperationException(
"No nameidentifier claim"
        return new Claim(Constants.ClaimTypes.Subject, nameId.Value);


If your IdP uses a different mapping, simply change the implementation of GetSubject. If you want to wire up a different claims transformer altogether, you can find the relevant code in global.asax.

If you don’t use an IdP at all, you can also add a local login form to AS or switch to Windows authentication. In that case simply run the claims transformer in PostAuthenticateRequest to provide the sub claim.

The second authentication related plumbing is for the OAuth2 resource owner password flow. Since AS does not do authentication, the credential validation needs to be delegated. By default we do that using WS-Trust to the same IdP that takes care of the web login. This is implemented in the WSTrustResourceOwnerCredentialValidation class, and configured in autofac.config:

<component type=" WSTrustResourceOwnerCredentialValidation …"
            service=" IResourceOwnerCredentialValidation … " >
    <parameter name="address"
               value="https://idsrv.local/issue/wstrust/mixed/username" />
    <parameter name="realm"
               value="urn:authorizationserver" />
    <parameter name="issuerThumbprint"
               value="BFF6C249A2FFAA51A959B422DAAEDCF10E8A38EB" />


Again, you can take control over that process be implementing IResourceOwnerCredentialValidation and wire it up in above config.

This entry was posted in AuthorizationServer, IdentityModel, IdentityServer, OAuth, WebAPI. Bookmark the permalink.

3 Responses to Authentication in AuthorizationServer

  1. ryanelfmanan says:

    How can I use Google or Facebook to be the IDP?

    • Please use the github issue tracker for further questions –

      but you have two options – either build google etc login into AS directly (e.g. using DNOA or Katana) – or use an IdP that supports it (e.g. IdentityServer or ACS).

  2. Pingback: Integrating AuthorizationServer with Auth0 |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s