02基礎(chǔ)篇6講06除了碼許可類型oauth2

2020-07-11OAuth2.0實戰(zhàn) 下使用授權(quán)碼許可授權(quán)，是不是過于復(fù)雜了，是不是根本就沒必要這樣？鋪的訂單數(shù)據(jù)。單數(shù)據(jù)的WebAPI，來提供為小明打單的功能。于是，為了保護這些場景下的WebAPI，又為了讓OAuth2.0更好地適應(yīng)現(xiàn)實世界的更多場景，來解決比如上述小兔軟件這樣的案例，OAuth2.0體系中還提供了資源擁有者憑么OAuth0還支持這種許可類型，而且編入了OAuth0的規(guī)范呢？很簡單，那就是這里不再有“第三方”的概念了。但是呢，如果每次小兔都是拿著小明的用戶名和密碼來通過調(diào)用WebAPI的方式，來訪問小明店鋪的訂單數(shù)據(jù)，甚至還有商品信息等，在調(diào)用這么多API的情況下，無疑增加了用戶如果是使用了token來代替這些“滿天飛”的敏感信息，不就能很大程度上保護敏感信息數(shù)據(jù)了嗎？這樣，小兔軟件只需要使用一次用戶名和密碼數(shù)據(jù)來換回一個token，進而通過token來訪問小明店鋪的數(shù)據(jù)，以后就不會再使用用戶名和密碼了。1：當(dāng)用戶訪問第三方軟件小兔時，會提示輸入用戶名和密碼。索要用戶名和密碼，2：grant_typepassword，告訴授權(quán)服務(wù)使用資源擁有者憑據(jù)許可MapMap<String,String>params=newHashMap<String,String>();StringaccessToken=3：access_token2StringappSecret=request.getParameter("app_secret");Stringusername=request.getParameter("username");Stringpassword=request.getParameter("password");pp_secretisnotavailable");return;sernameisnotavailable");asswordisnotavailable");return;StringaccessTokengenerateAccessToken(appId,"USERTEST");//生成訪問令牌acc到了這里，你可以掌握到一個信息：如果軟件是官方出品的，又要使用OAuth2.0來保護我們的WebAPI，那么你就可以使用小兔軟件的做法，采用資源擁有者憑據(jù)許可類型。無論是我們的架構(gòu)、系統(tǒng)還是框架，都是致力于解決現(xiàn)實生產(chǎn)中的各種問題的。除了資源擁有者憑據(jù)許可類型外，OAuth0許可類型。接下來，讓我們繼續(xù)看看這兩種授權(quán)許可類型吧。數(shù)據(jù)，比如獲取京東LOGO的圖片地址，這個LOGO信息不屬于任何一個第三方用戶，三方用戶。景下的授權(quán)，便是客戶端憑據(jù)許可，第三方軟件可以直接使用注冊時的app_id和app_secret來換回訪問令牌token的值。發(fā)起access_token的請求，所以這種授權(quán)許可也不需要刷新令牌。1：第三方軟件小兔通過后端服務(wù)向授權(quán)服務(wù)發(fā)送請求，grant_typeMapMap<String,String>params=newHashMap<String,String>();StringaccessToken=步驟2：在驗證app_id和app_secretaccess_token11StringgrantType=StringStringappId=idisnotavailable");return;StringappSecret=request.getParameter("app_secret");response.getWriter().write("app_secretisnotStringaccessTokengenerateAccessToken(appId,"USERTEST");//生成訪問令牌執(zhí)行的，比如純粹的JavaScript應(yīng)用，應(yīng)該如何使用OAuth2.0呢？在這種情況下，小兔軟件對于瀏覽器就沒有任何保密的數(shù)據(jù)可以隱藏了，也不再需要應(yīng)用密鑰app_secret的值了，也不用再通過授權(quán)碼code來換取訪問令牌access_token了。因為使用授權(quán)碼的目的之一，就是把瀏覽器和第三方軟件的信息做一個隔離，確保瀏覽器看不到第三方軟件最重要的訪問令牌access_token的值。因此，隱式許可授權(quán)流程的安全性會降低很多。在授權(quán)流程中，沒有服務(wù)端的小兔軟件相線框來表示小兔軟件，整個授權(quán)流程如下圖所示：Servlet的Get步驟1：用戶通過瀏覽器訪問第三方軟件小兔。此時，第三方軟件小兔實際上是嵌入瀏覽步驟2：這個流程和授權(quán)碼流程類似，只是需要特別注意一點，response_type的值變成了token，是要告訴授權(quán)服務(wù)直接返回access_token的值。隨著我們后續(xù)的講解，你會發(fā)現(xiàn)隱式許可流程是唯一在前端通信中要求返回access_token的流程。對，就這么“大膽”，但“不安全”。MapMap<String,String>params=newHashMap<String,String>();StringtoOauthUrl=URLParamsUtil.appendParams(oauthUrl,params);//構(gòu)造請求授權(quán)的步驟3：生成acccess_token11StringresponseType=StringStringredirectUri=request.getParameter("redirect_uri");StringappId=request.getParameter("app_id");//隱式許可流程（模擬），DEMOCODEStringaccessToken=generateAccessToken(appId,"USERTEST");//生成訪問令牌Map<String,String>params=newHashMap<String,String>();StringtoAppUrlURLParamsUtil.appendParams(redirectUri,params);//構(gòu)造第三OAuth2.0流程的話，也就是像上面我說的小兔這個例子，那么便可以直接使用隱式許可OAuth2.04OAuth2.0種各樣的變化，OAuth2.04就是獲取訪問令牌access_token的方式不同。最后，我通過一張表格來對比下：圖4OAuth2.0的4除了上面這張表格所展現(xiàn)的所有的授權(quán)許可類型中，授權(quán)碼許可類型的安全性是最高的。因此，只要具備使用授權(quán)碼許可類型的條件，我們一定要首先授權(quán)碼許可類型。所有的授權(quán)許可類型都是為了解決現(xiàn)實中的實際問題，因此我們還要結(jié)合實際的生產(chǎn)環(huán)我把今天用到的代碼放到 上，你可以點擊這個鏈接查看 05|如何安全、快速地接入OAuth 07|如何在移動App中使用OAuth1 21理論上講，沒有瀏覽器的情況下，也可以實現(xiàn)授權(quán)碼許可流程。這種流程需要一個useragseragent，不過不太清楚具體實踐中這一塊怎么處理的。作者回復(fù):在1OAuth2.0授權(quán)碼許可類型，這個是最安全的，需要用戶登錄與授權(quán)，返回授權(quán)碼給第三3 千Ryan1 吧，應(yīng)該是使用資源擁有者憑證許可。還有一個問題，隱式許可時，沒有es_t，那accesss_token過期了，每次過期都需要資源擁有者參與，再走一遍認證過程嘛？？這不是沒法在生產(chǎn)中使用嗎1