IdentityServer > Basic

IdentityServer Basic

Let's take a look at the glossaries and especially, OAuth2 flows.

IdentityServer?

It's a OpenID framework basing on .NET / Katana framework. We can call it OP ( OpenID Connect Provider )

OpenID Connect specification / OAuth2 specification

Protocol Terms

• OIDC ( OpenID Connect )
  A security layer based on OAuth2 ( which isn't IETF spec )
  
  
• OAuth2
  A RFC protocol for access control ( which is IETF spec )
  
  
• OP ( OpenID Connect Provider )
  STS ( Security Token Service ), Identity Provider, Authorization Server are pretty much the same thing.
  You can call it OP if it provides these kind of services below.
  
      1. Authenticate users in local account storage or via an external OP.
      2. Support session management and SSO ( Single Sign On ).
      3. Manage and authenticate clients. 
      4. Issue an identity token and an access token to a client.
      5. Validate the token itself.
  
  
• Client
  The one who requests a token from OP to access some resources or validate a user. A client must be registered in the client list of OP beforehand. Anything that's able to send a request can be called a client. ( eg. Web application, native mobile app, destop app, SPA app, Server process, and etc )
  
  
• User
  Means an user using a registered client.
  
  
• Scope
  This can be split into an identity scope and a resource scope. It's an identifier for a client to access a specific resource. This is packed with the request in flight.
  
  
• Scope > Identity Scope
  It represents an identity information called Claims. Name, an email address, and etc are modeled for the OpenID Connect spec.
  
  
• Scope > Resource Scope
  It's an identifier for accessing an API in a resource server. If your app has a calendar resource scope then you can show your scope and prove that you have the right to access the calendar API and get the resources ( eg. birthday event data ).
  
  
• Authentication / Token Request
  Client requests a token from an OP server. According to what scope you have, the OP server returns an identity token or an access token, or sometimes give you the both depending on the flow type.
  
  
• Identity Token
  It's a result for an authentication job. It includes an identifier, a subject claim, which is called "sub". It can further have an information regarding how it could be authenticated.
  
  
• Access Token
  A token for accessing to resources. Probably the most important token in OAuth protocol. This token has a client info in itself, or sometimes some user information together. A resource server can get to see if this client has the right to access this resource or not by sniffing the access token.
  
  
• Subject
  It's a primary key like thing in Claim. Claims can have the same properties each other ( eg. the same name ) so a claim always has a unique id. It's called "sub" in the protocol and you can tell this request includes a human or not by looking at this Subject object. 

Relevant Terms

• Claim
  It's an object in System.Security.Claims namespace.
  Imagine a baggage claim area in an airport. It is the claim, that you claim that I'm the owner of that bag.
  Since this Claim object represents "That's mine" voice, it has an issuer, a permission, and roles as its attributes.
  You can add more information to a dictionary the object has as a member.
  
  
• Bearer Token
  Bearer bonds mean a bond without any name taken in the paper, the same goes on this bearer token. It's like a plastic hotel key. If you accidently lost the key and then anybody who picked up the card can open the room's door. So if someone has the bearer token, he can access to the specific services the access token can access.
  
  
  
• Refresh Token
  It's for getting a fresh new access token. Normally a refresh token is a long-lived token whereas an access token is short-lived. So an app that has a long period of session can use a refresh token to get a new access token when the previous access token has expired. If the refresh token has expired, the app would have to reauthenticate itself again.
  
  
  
• JWT
  It stands for JSON Web Token. It's a RFC7519 spec.
  By JWT, you can transfer a claim info ( identity token or access token ) between two parties in a safe way.
  In IdentityServer you can choose an access token format as hashed string or JWT.
  
  
  
• Redirection URI
  You're gonna see this at the flow diagrams below. It's one of the properties of Client object. A client can set an URI to receive an authorization code or access token at there and that's the destination the redirection URI represents. Of course the URI should be registered at the time of the client is listed on the OP's client list. If a client app requests with somewhat different redirection URI, then the OP server will fail to validate the client properly, so there's no authorization code and access token for you.

Why do we use IdentityServer?

• Browser
  SPA, MVC, Traditional Web app clients.
  
  
• Native app
  Native mobile app, Desktop app clients.
  
  
• Server app
  any clients including a process running on a server.
  
  

Before IdentityServer came on the way, your application would have to validate the client identity and then when they tried to a web api again, yours painfully had to go through the same validation job again.

Your app needed to develop a login page, cookie management process, account management, registration code management process seperately. And if the app needed to scale out or expanding the domain, you would have to repopulate the same code. It's obviously no good for maintenance for sure.

That's why it's getting important to have a centered server to handle all the authentication and validation jobs.

OAuth?

In the traditional authentication between a client and a server, the client requested restricted resources and it used the resource owner's credential ( eg. id and passwords ) directly. Resource owner had to share the sensitive security information with third parties to let them access the resources. This causes several problems like this.

1. A third party application need to store the resource owner's credentials to request resources whenever it wants. And in most cases, the credential info is saved in plain texts.

2. A server must support a password authentication service even if the password has so many defects in terms of security.

3. Third party applications get to have way more privileges by having the resource owner's credentials. They are basically the same as resource owners, so restricting them by limiting some periods or limiting some specific groups isn't just possible.

4. A resource owner cannot set roles on third parties. He would have to revoke the rights from all of them.

5. Compromise of any third parties will leak everything bound to the credentials.

That's why OAuth protocol was popped out.

Flow?

OAuth2 has several flow types such as Authorization Code Flow, Implicit Flow, Resource Owner Password Flow, Client Credential Flow. The default setting is implicit flow in IdentityServer. Well they decided to set it up so because the majority number of implementations are done on web applications. Understanding these flow diagrams properly, or in a deep level, you should know exactly which part of your systems goes for Client, which one is for UserAgent, Resource owner in your development environment.

Real life example for understanding the entities in the flow.

An iPhone's owner Damon ( An end user ). All the pictures ( Resources ) taken from trips all around the world by the gadget. The owner of the cellphone is Damon, so he is a Resource Owner. The pics have been synchronized on iCloud ( Resource server ). The resource server completely doesn't know anything about the resource owner's credentials, what it does is just ask its own security layer, an OP server ( Authentication Server )

for an access token and use it to validate the credentials. Damon decided to put those pics up on Naver cloud. The Naver cloud needs a permission to access to iCloud ( Resource Server ), so it becomes a Client and requests the OP server for an access token to get those pictures from iCloud. The elements generating requests to the OP including some specific codes, programs, processes, and etc are all User Agent. Keep these in your mind and keep reading further below. These are going to be very handy.

Flow types

> Authorization Code

In this flow, the validation procedure only takes place between a resource owner and an authorization server, therefore you don't have to be worried about leaking resource owner's credentials. Authorization server finishes authenticating job and directly sends the authorization code to the Client right after that. This has some security benefits.

> Implicit

Implicit flow is an optimal grant type for a browser client application using script language like javascript. A client can get an access token and receive it directly from the OP as a result of resource owner's authorization grant. The reason why it's called implicit is because there's no authorization code issuing job for making an access token. ( Resource owner doesn't grant permission in person, it does implicitly )

While issuing an access token, the authorization server doesn't validate the client. In some cases, it performs authentication on the client by looking at the destination URI to which an access token was delivered. Implicit flow expects a fast responsiveness and it is a efficient way to deliver an access token to a browser application ( cuz it takes less network round trip ). So relatively weak security is the trade off for convenient.

The security compromise point is the F in the diagram. ( ref here 10.3 and 10.16 )

> Resource Owner Password

It's resource owner's password authentication. ( typically id and password ) An OP server authenticates a client with the resource owner's password and return an access token. It must be used when there's absolute trust between the resource owner and client.

> Client Credentials

Authorization grant under control of a client. You can use this flow when a client is also a resource owner. Something that will be shipped with an authorization server is the example.

> Authorization Code With Proof Key ( PKCE https://tools.ietf.org/html/rfc7636 )

The authorization code interception attack is the biggest concern in the authorization code flow. PKCE is the backup.

1. A client generates code_verifier everytime it makes a request.

2. A client makes a code challenge using the code_verifier ( SHA256 or plain )

3. A client sends a request to an OP server with this code challenge.

4. The OP Server combines the code challenge and authorization code. The code challenge lets you tract down which clients, when it did, and how it made this request, and The server can see if the client can parse the code challenge accordingly.

> Hybrid with proof key

Hybrid flow is practically a combination of the implicit + authorization code flow. Hybrid with proof key means PKCE concept comes into the hybrid flow group. To put it simply, you can come up with this flow when you are worried about the authorization code interception attack on hybrid flow.

When to use which flows? 

ref : https://auth0.com/docs/api-auth/which-oauth-flow-to-use