Saturday, November 30, 2019

Identity Server 4 With ASP.NET Core 2.0

Problem
How to use Identity Server 4 with ASP.NET Core 2.0
Solution
I am assuming you have the basic understanding of Identity Server. To know more, refer to its documentation
I’ll implement 3 projects here.
  1. Server – running on port 5000
  2. API (i.e. protected resource) – running on port 5001
  3. Client – running on port 5002
Auth. Server
Create an empty web application and copy Quickstart, Views, and wwwroot folders from GitHub. Create a Startup class.
Create a class Config and add the methods for getting API, identity, clients and users.
API
Create an API project and update its Startup class.
Create a Controller and protect using [Authorize] attribute.
Client
Create a web application and update its Startup class.
Add a Controller to access the API.
NoteYou can download the source code from my GitHub repository.
Discussion
IdentityServer4 website defines it as an OpenID Connect and OAuth 2.0 framework for ASP.NET Core that enables following features:
  • Centralize login logic for your applications
  • Single sign-on
  • Issues access tokens for APIs
  • Gateway to external identity providers like Google, Facebook etc.
  • Customizable
I’ll briefly discuss OAuth 2.0 and OpenID Connect here however for a much more in-depth discussion of OAuth 2.0 and OpenID Connect, I suggest looking at online courses and blog posts by Identity Server developer: Dominick Baier
OAuth 2 Flows
OAuth 2 provides several flows or grant types for various use cases. I personally group them into two categories; flows that require user interaction with authorization server and flows that don’t. Let’s first define the terms I’ll be using when discussing flows:
Definitions
  • User - the person using a Client and the owner of Protected Resource.
  • Client - the application that needs access to Protected Resource.
  • Protected Resource - the resource being protected from unauthorized access (e.g. Web API).
  • Server - the server that authorizes User and returns Access Tokens.
  • Access Token -  a secret key used to access Protected Resource.
  • Scopes - values based on which the access to Protected Resource features is limited
  • Redirect URI - the location where User returns after Auth. Server completes authorization
  • Client ID - Client’s identifier registered with the Auth. Server.
  • Client Secret - Client’s secret registered with the Auth. Server. This must be kept confidential.
Requiring User Interaction with Auth. Server
Implicit Grant
The flow is usually used for native/local/mobile clients and has following high-level steps:
  1. User accesses the Client.
  2. User is redirected to Auth. Server.
  3. User provides username/password.
  4. User is redirected back to Client with an Access Token.

    Note
    Access Token is exposed to the user.
  5. Client access the Protected Resource using the Access Token.
Note
it is recommended to use Authorisation Code instead of Implicit Grant.
Authorisation Code
The flow is usually used for web application clients and has following high-level steps:
  1. User accesses the Client.
  2. User is redirected to Auth. Server.
  3. User provides username/password.
  4. User is redirected back to Client with a code.

    NoteCode is exposed to the user.
  5. Client accesses the Auth. Server to exchange the code with an Access Token.

    NoteAccess Token is not exposed to the user.
  6. Client access the Protected Resource using the Access Token.
Not Requiring User Interaction with Auth. Server
Resource Owner Password Credentials
The flow is usually used for trusted clients and has following high-level steps,
  1. User access the Client and provide username/password.

    Noteusername/password is exposed to the Client.
  2. Client access to the Auth. Server to exchange username/password with an Access Token.
  3. Client access to the Protected Resource using the Access Token.
Client Credentials
The flow is usually used for client-server communication, without human involvement, and has the following high-level steps:
  1. Client access the Auth. Server to exchange Client ID and Secret with an Access Token.
  2. Client access the Protected Resource using the Access Token.
OpenID Connect
OpenID Connect is a layer on top of OAuth 2.0 and uses claims to communicate information about users. It provides services to verify user identity and obtain their profile information.
OpenID Connect uses OAuth 2.0 flows to obtain Identity Token, which asserts things like identity of the user (aka sub), issuing authority (aka iss), client (aka aud) and issue/expiry dates. The token is in JWT format and base-64 string.
Source Code

No comments:

Post a Comment

Lab 09: Publish and subscribe to Event Grid events

  Microsoft Azure user interface Given the dynamic nature of Microsoft cloud tools, you might experience Azure UI changes that occur after t...