Skip to content


Repository files navigation

Authorization Server Implementation in C#


This is an authorization server implementation in C# which supports OAuth 2.0 and OpenID Connect.

This implementation is written using ASP.NET Core API and authlete-csharp library which is provided as a NuGet package Authlete.Authlete.

This implementation is DB-less. What this means is that you don't have to manage a database server that stores authorization data (e.g. access tokens), settings of the authorization server itself and settings of client applications. This is achieved by using Authlete as a backend service.

Please read New Architecture of OAuth 2.0 and OpenID Connect Implementation for details about the architecture of Authlete. True engineers will love the architecture ;-)

The primary advantage of this architecture is in that the backend service can focus on implementing OAuth 2.0 and OpenID Connect without caring about other components such as identity management, user authentication, login session management, API management and fraud detection. And, consequently, it leads to another major advantage which enables the backend service (implementation of OAuth 2.0 and OpenID Connect) to be combined with any solution of other components and thus gives flexibility to frontend server implementations.


Apache License, Version 2.0

Source Code

How To Run

  1. Download the source code of this authorization server implementation.

     $ git clone
     $ cd csharp-oauth-server/AuthorizationServer
  2. Edit the configuration file to set the API credentials of yours.

     $ vi
  3. Start the authorization server on http://localhost:5000.

     $ dotnet run

Configuration File

csharp-oauth-server refers to as a configuration file. If you want to use another different file, specify the name of the file by the environment variable AUTHLETE_CONFIGURATION_FILE like the following.

$ export


This implementation exposes endpoints as listed in the table below.

Endpoint Path
Authorization Endpoint /api/authorization
Token Endpoint /api/token
JWK Set document Endpoint /api/jwks
Configuration Endpoint /.well-known/openid-configuration
Revocation Endpoint /api/revocation
Introspection Endpoint /api/introspection

The authorization endpoint and the token endpoint accept parameters described in RFC 6749, OpenID Connect Core 1.0, OAuth 2.0 Multiple Response Type Encoding Practices, RFC 7636 (PKCE) and other specifications.

The JWK Set document endpoint exposes a JSON Web Key Set document (JWK Set) so that client applications can (1) verify signatures by this OpenID Provider and (2) encrypt their requests to this OpenID Provider.

The configuration endpoint exposes the configuration information of this OpenID Provider in the JSON format defined in OpenID Connect Discovery 1.0.

The revocation endpoint is a Web API to revoke access tokens and refresh tokens. Its behavior is defined in RFC 7009.

The introspection endpoint is a Web API to get information about access tokens and refresh tokens. Its behavior is defined in RFC 7662.

Authorization Request Example

The following is an example to get an access token from the authorization endpoint using Implicit Flow. Don't forget to replace {client-id} in the URL with the real client ID of one of your client applications. As for client applications, see Getting Started and the document of Developer Console.


The request above will show you an authorization page. The page asks you to input login credentials and click "Authorize" button or "Deny" button. Use one of the following as login credentials.

Login ID Password
john john
jane jane

Of course, these login credentials are dummy data, so you need to replace the user database implementation with your own.


How to customize this implementation is described in Basically, you need to do programming for end-user authentication because Authlete does not manage end-user accounts. This is by design. The architecture of Authlete carefully seperates authorization from authentication so that you can add OAuth 2.0 and OpenID Connect functionalities seamlessly into even an existing web service which may already have a mechanism for end-user authentication.

See Also


Purpose Email Address