在該協定中，使用令牌（id_token）替換oauth2的access_token，id_token生成時使用私鑰進行簽名，使用時用公鑰進行校驗。使用json資料格式進行傳輸，并支援各類加密算法（如rsa）。
結合api網關的使用場景，實作方案分為兩個重要的部分：
1. authorization server（as）：認證伺服器，負責生成id_token并管理公鑰私鑰對。
1) consumer（調用者）向api網關發送擷取id_token認證請求，比如：通過使用者名和密碼（u+p）的方式。
2) api網關透傳該請求到as。
3) as向provider（服務提供方）發送認證使用者資訊請求。
4) provider響應認證結果，若失敗則直接響應錯誤資訊。
5) 認證結果成功，as生成id_token，id_token中包含了user資訊（可擴充，也可包含其他必要資訊）。
6) api網關将as傳回的id_token響應給consumer。
2. resource server（rs）：資源伺服器，負責校驗id_token，并解析出相應的資訊。
rs在整個體系中擔任id_token消費者角色，隻有id_token校驗通過，才能将請求轉發給provider。
1) consumer用帶有id_token的參數去請求api網關。
2) api網關會儲存校驗所使用的公鑰，驗證并解析id_token擷取其中的user資訊傳給provider，若驗證失敗則直接傳回錯誤資訊。
3) provider處理請求并傳回結果給api網關。
4) api網關透傳provider響應的結果給consumer。
以上隻是簡單描述了下openid connect結合api網關應用場景的實作方案，但并不是唯一的。比如在這個實作方案中，as是一套獨立部署的應用，其實也可以把它內建到provider中去，或者內建到api網關中；同樣的，rs也可以內建到provider中去，大家可以根據不同的實際情況采取不同的方案。