Skip to content
This repository has been archived by the owner. It is now read-only.
Sample implementation of an OAuth2 Authorization Server
C# CSS JavaScript
Branch: master
Clone or download
Latest commit cb88f01 Aug 22, 2016
Type Name Latest commit message Commit time
Failed to load latest commit information.
samples/Flows Removed "dead code" in sample Mar 8, 2014
source Updated code so that redirection is allowed only over SSL Oct 23, 2015
.gitattributes Added .gitattributes May 4, 2013
.gitignore Updated gitignore for exclude data protection keys Jul 12, 2013 Update Aug 22, 2016
license.txt Update license.txt Jun 17, 2013


AuthorizationServer is the foundation for implementing application and API authorization. As a first step, we provide an implementation of the OAuth2 authorization framework.

Important AuthorizationServer is not really maintained anymore - read here for details.


We support the following primitives:

Applications Applications are containers for settings (token lifetime, key material, audience…) and scopes. Every application gets its own entry point in the URL structure, e.g. ../myapp/oauth/authorize and ../myapp/oauth/token.

Scopes Scopes represent permissions a client can ask for. They will be shown on consent screens, so the resource owner can grant (or deny) access. A scope also defines which clients can request it.

Clients A client has a client ID and a secret. A client can use exactly one OAuth2 flow to request tokens (code, implicit, resource owner credentials, client credentials). A client has a list of allowed redirect URIs for flows that require a callback.

Access Tokens An access token will contain JWT standard claims like iss (issuer), aud (audience), nbf (not before), exp (expiration). In addition it will contain information about the subject (sub claim), the client that requested the token as well as the requested scopes.

Flows We support all OAuth2 flows like authorization code, implicit, resource owner and client credentials flow. In addition you can extend the token endpoint to support assertion flow, which enables delegation and federation scenarios.


AS deliberately doesn't do authentication. It solely focuses on authorization. The default configuration assumes AS is a relying party to some WS-Federation identity provider (e.g. IdentityServer, ADFS, Windows Azure Active Directory or Azure Access Control Service). You can of course customize that in any way you want, e.g. add a local login page.

AS has only a single requirement when it comes to identity of the resource owner: the current principal must contain a claim of type "sub" (subject). You can adapt to your own claims structure using the ClaimsTransformer class in the web host project.

See the [wiki] ( for more information.

You can’t perform that action at this time.