Multi-Factor Authentication Design with IdentityServer4 and ASP.NET Core 2.0 (2)
Chapter 2
From previous chapter, I have designed the Verification Pipeline Diagram. There are 3 sections.
1. Verification Authority
The part used to verify each step by the input is Identity Claims and Payload. Identity Claims comes from the verified claims of previous step and Payload is derived from the input of the interface layer.
OnVerify was created as a method to get Identity Claims and Payload, then to verify the input and return the claims.
OnForward was created as a method and instant execute after OnVerify of previous authority, because it was designed to work seamlessly.
Verification Authority requires a payload for verification, such as OTPAuthority. The otp value must be specified as well.
Payload => new string[] { "otp" }IAuthority Interface
Implementation of AccountAuthority and OTPAuthority
Example from the Verification Pipeline Diagram designed in Chapter 1
OnVerify of AccountAuthority : The first is Empty Claims (because there is no previous Verify Authority).
At the same time, OnForward of OTPAuthority works immediately. Then we will get the first two claims from :
OnVerify — verified claims of AccountAuthority.
OnForward — forward claims of OTPAuthority.
2. Authority Issuer
The Verification Authority is in the pipeline. It must be managed. This is the responsibility of the Authority Issuer.
The main function of Authority Issuer is to support the Authority’s Register for each verification step. And ordering OnVerify / OnFoward When the Verify Authority is registered, such as Verify AccountAuthority, Authority Issuer will call AccountAuthority.OnVerify, OTPAuthority.OnForward, respectively.
Because OTPAuthority.OnForward will send OTP to the phone number obtained from verified claims at AccountAuthority.OnVerify. Then return to the forward claims, which contains otp_id, otp_hash
Authority Issuer will combine the two claim types together and then transform it into a JWT Token forwarded to the Interface Layer.
At the step of OTP verification, Authority Issuer converts a token to Identity Claims and then pushing together with incoming payload to OTPAuthority.OnVerify.
The process is repeated as above, according to the authorities that is registered in the Verification Pipeline.
Verification Pipeline that is created through Authority Issuer can have different verification procedures, but use the same Authority (reusable).
Implementation of Authority Issuer
3. Authenticator
The last ingredient that is indispensable is Authenticator which is related to the middle line in the diagram is written as Identifier.
Let’s talk about Identifier first … Identifier is the key-value to link each Authority together. It is the agreement to send the key-value among the verified process through the last Authority (Authenticator). Authenticated claims, which are the final claims to verify with the system.
Because Authenticator is the last authority to be restored the authenticated claims, which is different from the normal authority that returned the claims has come up with another Interface.
Authenticator has duty to twist /change the Identifier to match the system verification key. In this case, the identifier is in a format that matches the authentication system, so it does not twist / change anything.
The core of the system has been done. Here we will talk about the Interface Layer that is Integrate with Identity Server in the next chapter.
Chapter 3 : Implementation of the system
