oauth認證

⑴ 「oauth」的中文意思

oauth本質一種開放的協議，對象是第三方可以使用OAUTH認證服務
簡介

OAUTH協議為用戶資源的授權提供了一個安全的、開放而又簡易的標准。同時，任何第三方都可以使用OAUTH認證服務，任何服務提供商都可以實現自身的OAUTH認證服務，因而OAUTH是開放的。業界提供了OAUTH的多種實現如PHP、JavaScript，Java，Ruby等各種語言開發包，大大節約了程序員的時間，因而OAUTH是簡易的。互聯網很多服務如Open API，很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH認證服務，這些都足以說明OAUTH標准逐漸成為開放資源授權的標准。
在官方網站的首頁，可以看到下面這段簡介：
An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.
大概意思是說OAUTH是一種開放的協議，為桌面程序或者基於BS的web應用提供了一種簡單的，標準的方式去訪問需要用戶授權的API服務。OAUTH類似於Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。

⑵ 手機應用中使用OAuth認證，如何解決信任問題

設置步驟如下：

• 打開設置菜單，找到許可權管理選項。

• 打開後你可以看到很多許可權。

• 比如讀取聯回系人的許可權。

• 如果答你不想讓某個軟體讀取你的聯系人，點開它選擇禁止即可。

• 還可以查看某個軟體的所有權限，打開設置里的許可權管理後，點右側的應用。

• 點開後軟體的所有許可權都會顯示在其中，如果比較信任某個軟體，還可以選擇信任選項。

⑶ REST API 只給自己的APP提供介面，需要oauth認證嗎

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存session, 因此用session token來標示自己就夠了，session/state由api server的邏輯處理。
如果你的後端不是stateless的rest api, 那麼你可能需要在app里保存session. 可以在app里嵌入webkit,用一個隱藏的browser來管理cookie session.
session 和 oauth token 並不矛盾，作為身份認證 token 安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在伺服器端保存一些狀態

⑷ 新浪OAuth和Basic Auth兩種方式的區別

開放平台有兩種認證方式，一種是Basic Auth，一種是OAuth。
1、Basic Auth（HTTP Auth）
Basic Auth簡單點說明就是每次請求API時都提供用戶的username和password。
。這種方式優點和缺點都很明顯。
優點：
u 使用非常簡單，
u 開發和調試工作簡單，
u 沒有復雜的頁面跳轉邏輯和交互過程；
u 更利於發起方控制；
缺點：
u 安全性低，每次都需要傳遞用戶名和密碼，用戶名和密碼很大程度上存在被監聽盜取的可能；
u 同時應用本地還需要保存用戶名和密碼，在應用本身的安全性來說，也存在很大問題；
u 開放平台服務商出於自身安全性的考慮（第三方可以得到該服務商用戶的賬號密碼，對於服務商來說是一種安全隱患），未來也會限制此認證方式（Twitter就計劃在6月份停止Basic Auth的支持）
u 用戶如果更改了用戶名和密碼，還需要重新進行密碼校驗的過程。
2、OAuth
OAuth為用戶資源的授權提供了一個安全、開放的標准，將會是以後開發平台普遍遵守的，目前Twitter、Sina微博、豆瓣、Google等都提供對它的支持。它分為幾個交互過程：
1）應用用APP KEY和APP SECRET換取OAuth_token；
2）應用將用戶引導到服務商的頁面對該OAuth_token進行授權（可能需要輸入用戶名和密碼）；
3）服務商的頁面跳轉回應用，應用再根據參數去服務商獲得Access Token；
4）使用這個Access Token就可以訪問API了。
上述過程如下圖所示：
OAuth認證過程
OAuth的優點：
u 安全性高，用戶的賬戶和密碼只需要提供一次，而且是在服務商的頁面上提供，防止了Basic Auth反復傳輸密碼帶來的安全隱患；
u Access Token訪問許可權僅限於應用，被竊取不會影響用戶在該服務商的其他服務；
u Access Token即使被監聽丟失了隨時可以撤銷，不像密碼丟失可能就被別人篡改了；
u 用戶修改了密碼也不會影響該應用的正常使用。
OAuth和Basic Auth兩種方式的區別, OAuth是一種比較通用的，安全的認證方式，不需要用戶名密碼，只需要用戶授權；basic auth是一種基於用戶名密碼的認證，每次訪問都需帶上用戶的用戶名密碼。

⑸ oauth認證服務端怎麼生成app key和app secret

oauth認證服務端的提供商會提供相應的界面讓你注冊，注冊後就會分配給你key和secret。
比如 網路雲平台，騰訊雲平台，新浪開發者平台 之類的。

⑹ OAUTH，OPENID，SAML，CAS做統一認證與授權時有什麼區別

OpenID是Authentication
OAuth是Authorization

前者是網站對用戶進行認證，讓網站知道逗你是你所聲稱的URL的屬主地
後者其實並不包括認證，只不過逗只有認證成功的人才能進行授權地，結果類似於逗認證+授權地了。OAuth相當於：A網站給B網站一個令牌，然後告訴B網站說根據這個令牌你可以獲取到某用戶在A網站上允許你訪問的所有信息

如果A網站需要用B網站的用戶系統進行登錄（學名好像叫federated login），它可以

選擇OpenID認證，然後通過attribute exchange獲取用戶的昵稱或其他通過OpenID暴露出來的用戶屬性，或者
選擇OAuth認證，獲取到token後再用token獲取用戶昵稱或其他允許被訪問的信息

⑺ OpenID 和 OAuth 有什麼區別

OpenID是Authentication
OAuth是Authorization

前者是網站來對用戶進行認自證，讓網站知道「你是你所聲稱的URL的屬主」
後者其實並不包括認證，只不過「只有認證成功的人才能進行授權」，結果類似於「認證+授權」了。OAuth相當於：A網站給B網站一個令牌，然後告訴B網站說根據這個令牌你可以獲取到某用戶在A網站上允許你訪問的所有信息

如果A網站需要用B網站的用戶系統進行登錄（學名好像叫federated login），它可以

選擇OpenID認證，然後通過attribute exchange獲取用戶的昵稱或其他通過OpenID暴露出來的用戶屬性，或者
選擇OAuth認證，獲取到token後再用token獲取用戶昵稱或其他允許被訪問的信息

⑻ oauth2.0怎麼實現單點登錄

要實現SSO，需要實現以下主要的功能：所有的應用系統共享一個身份認證系統。統一的身份認證系統是SSO的前提，認證系統的主要功能是將用戶的登錄信息和用戶信息庫相比較，對用戶進行登錄認證。認證成功後，認證系統應該生成統一的認證標志（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。所有應用系統能夠識別和提取ticket信息要實現SSO的功能，讓用戶只登錄一次，就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對ticket進行識別和提取，通過與認證系統的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。以上內容都來自網路。 如何使用CAS實現單點登錄一、簡介CAS（Central Authentication Server中央驗證系統）是耶魯大學研發的單點登錄系統。系統為了安裝考慮默認是需要證書驗證的。本人使用的環境為：apache-tomcat-6.0.30(原來用的是tomcat7，但中途遇到了8443埠無法驗證的問題，懷疑是版本的原因，因此換成了tomcat6。PS：最後找出了原因是域名的問題，後面將會提到)。

⑼ 新浪微博OAuth2.0 認證怎麼實現自動登錄

根據Twitter的API Wiki，基本的OAuth驗證workflow如下：
1. 程序利用 http://api.twitter.com/oauth/request_token來從twitter.com那裡獲取一個request token。
2. 然後程序引導用戶到 http://api.twitter.com/oauth/authorize頁面。
3. 用戶如果同意授權，twitter.com則會顯示一個7位數字的PIN碼。
4. 用戶需要將PIN碼復制，然後回到程序那裡。
5. 之後程序要提示用戶輸入得到的PIN碼。
6. 然後程序將PIN碼作為參數oauth_verifier的值,接著調用 http://api.twitter.com/oauth/access_token去核實PIN碼，從而將request_token 換成access_token。
7. Twitter之後會返回一個access_token，程序就此token來生成之後的OAuth簽名。

⑽ OAuth2.0的認證授權過程

在認證和授權的過程中涉及的三方包括：
1、服務提供方，用戶使用服務提供方來存儲受保護的資源，如照片，視頻，聯系人列表。
2、用戶，存放在服務提供方的受保護的資源的擁有者。
3、客戶端，要訪問服務提供方資源的第三方應用，通常是網站，如提供照片列印服務的網站。在認證過程之前，客戶端要向服務提供者申請客戶端標識。
使用OAuth進行認證和授權的過程如下所示:
用戶想操作存放在服務提供方的資源。
用戶登錄客戶端向服務提供方請求一個臨時令牌。
服務提供方驗證客戶端的身份後，授予一個臨時令牌。
客戶端獲得臨時令牌後，將用戶引導至服務提供方的授權頁面請求用戶授權。在這個過程中將臨時令牌和客戶端的回調連接發送給服務提供方。
用戶在服務提供方的網頁上輸入用戶名和密碼，然後授權該客戶端訪問所請求的資源。
授權成功後，服務提供方引導用戶返回客戶端的網頁。
客戶端根據臨時令牌從服務提供方那裡獲取訪問令牌。
服務提供方根據臨時令牌和用戶的授權情況授予客戶端訪問令牌。
客戶端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。 OAuth 1.0在2007年的12月底發布並迅速成為工業標准。
2008年6月，發布了OAuth 1.0 Revision A，這是個稍作修改的修訂版本，主要修正一個安全方面的漏洞。
2010年四月，OAuth 1.0的終於在IETF發布了，協議編號RFC 5849。
OAuth 2.0的草案是在2011年5月初在IETF發布的。
OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
OAuth是個安全相關的協議，作用在於，使用戶授權第三方的應用程序訪問用戶的web資源，並且不需要向第三方應用程序透露自己的密碼。
OAuth 2.0是個全新的協議，並且不對之前的版本做向後兼容，然而，OAuth 2.0保留了與之前版本OAuth相同的整體架構。
這個草案是圍繞著 OAuth2.0的需求和目標，歷經了長達一年的討論，討論的參與者來自業界的各個知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。
OAuth 2.0的新特性： User-Agent Flow – 客戶端運行於用戶代理內（典型如web瀏覽器）。
Web Server Flow – 客戶端是web伺服器程序的一部分，通過http request接入，這是OAuth 1.0提供的流程的簡化版本。
Device Flow – 適用於客戶端在受限設備上執行操作，但是終端用戶單獨接入另一台電腦或者設備的瀏覽器
Username and Password Flow – 這個流程的應用場景是，用戶信任客戶端處理身份憑據，但是仍然不希望客戶端儲存他們的用戶名和密碼，這個流程僅在用戶高度信任客戶端時才適用。
Client Credentials Flow – 客戶端適用它的身份憑據去獲取access token，這個流程支持2-legged OAuth的場景。
Assertion Flow – 客戶端用assertion去換取access token，比如SAML assertion。
可以通過使用以上的多種流程實現Native應用程序對OAuth的支持（程序運行於桌面操作系統或移動設備）
application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.
持信人token
OAuth 2.0 提供一種無需加密的認證方式，此方式是基於現存的cookie驗證架構，token本身將自己作為secret，通過HTTPS發送，從而替換了通過 HMAC和token secret加密並發送的方式，這將允許使用cURL發起APIcall和其他簡單的腳本工具而不需遵循原先的request方式並進行簽名。
簽名簡化：
對於簽名的支持，簽名機制大大簡化，不需要特殊的解析處理，編碼，和對參數進行排序。使用一個secret替代原先的兩個secret。
短期token和長效的身份憑據
原先的OAuth，會發行一個 有效期非常長的token(典型的是一年有效期或者無有效期限制)，在OAuth 2.0中，server將發行一個短有效期的access token和長生命期的refresh token。這將允許客戶端無需用戶再次操作而獲取一個新的access token，並且也限制了access token的有效期。
角色分開
OAuth 2.0將分為兩個角色：
Authorization server負責獲取用戶的授權並且發布token。
Resource負責處理API calls。