上一篇寫了shiro的啟動加載過程的源碼分析，現在來看看相對簡單點的認證的流程源碼，先來看看官方的流程圖再對照我們日常的邏輯代碼。比較一下
簡單的解釋下上圖的步鄹：1.生成subject并且調用login(token)方法；2.調用securityManager的login()方法；3和4.進入到doGetAuthenticationInfo（）方法進行真正的認證邏輯；5.在realm中查詢資料源和傳入的token比較，有比對的就是認證成功。
再看看自定義的realm;是繼承AuthorizingRealm的這點很重要
總結一下上面的，其實說到底shiro認證的流程就是上面兩個截圖完成的，下面我們來分析一下源碼，看看是怎麼個過程
首先：
點進去是DelegatingSubject實作了Subject
接着往裡面找，找到了DefaultSecurityManager類的login()
接着進入了
繼續跟着源碼走，我們來到了
很多情況當我們看到Abstract開頭的類的時候就離真正的目标不遠了（因為abstract有部分實作和接口方法，承上啟下的作用，上面的幾張截圖在這裡講解一下：認證器的實作類，SecurityMananger也繼承自Authenticator，通過檢視AuthenticatingSecurityManager源碼其實就是Authenticator的代理。而真正實作認證功能的Authenticator實作類隻有一個ModularRealmAuthenticator，從類的名字可以看出這個認證器的實作原理——子產品化認證器：一個Realm就是一個認證子產品。
下面來看看單一的realm的doSingleRealmAuthentication（）方法
進入到了Realm接口裡面
繼續找他的實作進入到了AuthenticatingRealm類（這個類就是我們開頭說的要注意的，他是我們自定義的my）
最後一次點進去
為什麼找到自定義realm裡的實作了呢，看看繼承關系就知道了
到這裡就分析的差不多了，剩下的就是我們自定義MyShiroRealm裡面的doGetAuthenticationInfo方法進行認證。
最後,你以為就這樣就結束了？？？敲代碼是不可能的，這輩子都不可能！
忘記了這張圖麼？
是的，借用武器大師一句話：我又回來啦。那麼認證憑證生成了，下面我們要去認證了；
老辦法點進去看assertCredentialsMatch()看看是怎麼認證的，這是 void 方法，不會傳回隻會抛異常，是以應該在這裡判斷傳回是 true 還是 false
點進去doCredentialsMatch()，我擦，發現是個接口有四個實作類（看名字就知道是加密算法的大佬，惹不起，惹不起），我們的認證方法doCredentialsMatcher()也有這四個實作方法,我們看一下最難（簡單）的實作
今天的内容總結一下：
1.建立AuthenticationToken，然後調用subject.login(token)方法進行登入認證；
2.Subject委托給SecurityManager；
3.SecurityManager委托給Authenticator接口；
4.
Authenticator接口調用 MyShiroRealm 擷取登入資訊,進行認證。
最後，說實話我感覺認證的源碼比啟動加載簡單很多，跟着源碼點進去就行了，自己也是個菜雞，有什麼不對的，請各位老鐵多多指教，多多評論，謝謝啦！