Resource Server Implementation in C#
Switch branches/tags
Nothing to show
Clone or download

Resource Server Implementation in C#


This is a resource server implementation in C#. It supports a userinfo endpoint defined in OpenID Connect Core 1.0 and includes an example of a protected resource endpoint that accepts an access token in the ways defined in RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage).

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

To validate an access token presented by a client application, this resource server makes an inquiry to the Authlete server. This means that this resource server expects that the authorization server which has issued the access token uses Authlete as a backend service. csharp-oauth-server is such an authorization server implementation and it supports OAuth 2.0 and OpenID Connect.


Apache License, Version 2.0

Source Code

About Authlete

Authlete is a cloud service that provides an implementation of OAuth 2.0 & OpenID Connect. By using the Web APIs provided by Authlete, you can develop a DB-less authorization server and/or OpenID provider. "DB-less" here means that you don't have to manage a database server that stores authorization data (e.g. access tokens), settings of authorization servers and settings of client applications. These data are stored in the Authlete server on cloud.

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.

How To Run

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

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

     $ vi
  3. Start the resource server on http://localhost:5001/.

     $ dotnet run

Configuration File

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

$ export


This implementation exposes endpoints as listed in the table below.

Endpoint Path
UserInfo Endpoint /api/userinfo
Time Endpoint /api/time

UserInfo Endpoint

The userinfo endpoint is an implementation of the requirements described in 5.3. UserInfo Endpoint of OpenID Connect Core 1.0.

The endpoint accepts an access token as a Bearer Token. That is, it accepts an access token via Authorization: Bearer {access-token} or by a request parameter access_token={access-token}. See RFC 6750 for details.

The endpoint returns user information in JSON or JWT format, depending on the configuration of the client application. If both userinfo_signed_response_alg and userinfo_encrypted_response_alg of the metadata of the client application are not specified, user information is returned as a plain JSON. Otherwise, it is returned as a serialized JWT. Authlete provides you with a Web console (Developer Console) to manage metadata of client applications. As for metadata of client applications, see 2. Client Metadata in OpenID Connect Dynamic Client Registration 1.0.

User information returned from the endpoint contains claims of the user. In short, claims are pieces of information about the user such as a given name and an email address. Because Authlete does not manage user data (although it supports OpenID Connect), you have to provide claim values. It is achieved by implementing IUserInfoRequestHandlerSpi interface.

In this resource server implementation, UserInfoRequestHandlerSpiImpl is an example implementation of IUserInfoRequestHandlerSpi interface and it retrieves claim values from a dummy database. You need to modify the implementation to make it refer to your actual user database.

Time Endpoint

The time endpoint implemented in this resource server is just an example of a protected resource endpoint. Its main purpose is to show how to validate an access token at a protected resource endpoint.

The path of the time endpoint is /api/time. Because the endpoint supports all the three ways defined in RFC 6750, you can pass an access token to the endpoint by any means of the following.

# RFC 6750, 2.1. Authorization Request Header Field
$ curl -v http://localhost:5001/api/time \
       -H 'Authorization: Bearer {access_token}'
# RFC 6750, 2.2. Form-Encoded Body Parameter
$ curl -v http://localhost:5001/api/time \
       -d access_token={access_token}
# RFC 6750, 2.3. URI Query Parameter
$ curl -v http://localhost:5001/api/time\?access_token={access_token}

The time endpoint returns information about the current time (UTC) in JSON format. The following is an example response.

  "year":        2018,
  "month":       1,
  "day":         8,
  "hour":        9,
  "minute":      46,
  "second":      10,
  "millisecond": 15

As for generic and Authlete-specific information regarding how to protect Web APIs by OAuth 2.0 access tokens, see Protected Resource in Authlete Definitive Guide.

See Also


Purpose Email Address