關於如何在Android、Java等非微軟平臺上建立高信任的SharePoint應用程式

dosboy發表於2014-10-23

關於如何在非微軟平臺上建立高信任的SharePoint應用程式

原文：http://blogs.msdn.com/b/kaevans/archive/2014/07/14/high-trust-sharepoint-apps-on-non-microsoft-platforms.aspx

1.前言

開篇明之，哥無程式碼釋出，也不提供解決方案。我只是說明在非微軟技術平臺上建立低信任或是高信任應用程式是非常自由的(PS:也是非常痛苦的)。作為一個微軟技術的研發者，我也長時間沒有寫Java或是PHP程式碼了，文中吾力所不及給每一種平臺建立示例程式碼，拋磚以引玉吧。

當你去建立一個SharePoint 2013應用程式時，Visual Studio 2013，會讓你選擇：

1、使用Azure ACS

2、使用一個證照

這個選項就意味著在問，目標 SharePoint 伺服器場如何定義信任設定,並把相關設定儲存在Web.config檔案中。要麼你使用低信任ACS設定“client ID”和"client secret"或是使用高信任來設定"client ID" 、"證照路徑"和“證照密碼”。

2.理解OAuth和信任

通過這個PodCast, Office 365 Developer Podcast: Episode 002 with Radi Atanassov, Radi 詳述了SharePoint 使用OAuth ，並且把它形象地稱為 “三角驗證” ，當把應用設定成使用Azure ACS的時候，應用需要去與ACS通訊，提供一個“Refresh Token”，並且獲得一個Access Token， “Refresh Token” 是應用程式從SharePoint 的伺服器取得的,但這個"Refresh Token" 也是Azure ACS 之前發給SharePoint的。在這個模式下, 應用程式和SharePoint伺服器，不直接相信對方，而是通過Azure ACS 建立兩兩信任關係, 所以我們叫這“低信任”. 如果要更進一步理解這種“OAuth舞步”, 去這個URL 看我們的2013 session, Understanding Authentication and Permissions with Apps for SharePoint and Office,

低信任模型既可以被Office 365使用也可以被獨立的SharePoint 2013伺服器使用。

可殘酷的現實，總是發生！很多客戶根本沒有辦法去設定企業內部的SharePoint 2013與Azure ACS通訊，因為Azure ACS是微軟的伺服器，（企業內部的SharePoint 2013不允許連線外網，就算SharePoint 2013可以連外網有些國家也有防火牆不允許訪問國外某些網站）。很好！產品團隊於是可以不選擇Azure ACS，作為專業人士的我們也要清楚，對於OAuth 2.0來說，Azure ACS實現了S2S協議那可是微軟王國標準的OAuth 2.0作法，那是有國際範的。在“高信任”的認證方案裡，因為我們考慮到SharePoint 伺服器與APP 是2個非常鐵的哥們，不需要第三方去保證什麼。APP 使用X.509證照去給“TOKEN”簽名，然後SharePoint 再對這個簽字進行信任。

“高信任”，並不代表“高授權”，不是說APP可以直接去刪除或是幹掉伺服器裡的東西，“授權”還是通過使用APP的這個人來決定的。只不過APP可以操縱OAuth2 access token建立的過程，不需要微軟的ACS伺服器來搞定。SharePoint 場的管理員使用公鑰註冊一個“信任的安全TOKEN頒發者” SPTrustedSecurityTokenIssuer, 然後App 使用這個證照的私鑰簽名，正因為私鑰的特性，所以 SharePoint 會信任這個APP。

可喜的是獨立的伺服器可以選擇２者，而Office 365的APP是沒有辦法使用“高信任” 模式的, 因為作為一個微軟開發者的你，黑不到OFFICE　３６５的伺服器裡去建立證照！.

再說了：人家微軟的Office 365不信任微軟的ACS服務，難道信任你的APP不成。

3.低信任APP與非微軟平臺

如果你開發基於Office 365的程式上，哥勸你就直接使用“低信任APP”，這也簡單，對於APP開發者的你也不管簽名發證照的事情，在網頁上申請Client ID和 Client Secret後，在你的程式碼裡就是寫幾個程式儲存一Token之類，就行了。網上這種文章，多如牛毛，例如：1. Todd Baginski 對於Node.js 上開發SharePoint 作了非常精彩的演講。也釋出了示例PHP操縱SharePoint 2013 SharePoint 2013: Perform operations on SharePoint Document Library from PHP site. 在這個模型裡，要用到 JWT library 庫去解析由 SharePoint 發給你的context token ，過程就是得到 ACS URL, 把Refresh token 提交去得到access token.

2. 同樣，對於你自主的SharePoint網站建立一個低信任APP也是很有可能的，下面的文章真是大拿之作：如何使用Office 365去驗證一個自主SharePoint 網站的提供商承APP。

How to: Use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site.

在這個模型裡，你建立一個Office365的tenant，然後建立一個信任從你的伺服器到Office 365的伺服器，你不需要對於Office 365做任何配置，你只是需要它去讀取Azure ACS給你預備的名稱空間。一但配置好，無論它是不是微軟平臺，你就可以使用Client ID和Client Secret. 在自主的SharePoint服務場配置完畢後，你不需要擔心管理X.509證照或是證照頒發者的問題，你也不需要擔心開發人員有X.509密碼，可能引起的安全問題，看了這篇文章，你就有點懷疑我們為啥非要搞出一個“高信任”模式呢？？

建立一個ACS代理(在你的獨立SharePoint 伺服器場)
安裝你的SharePoint的簽字證照到你Office 365的tenancy.
把合格的域名加入到你SharePoint 2013場（這個場你想去執行APP），在你的Office 365 tenancy服務的princels名稱.
在你的伺服器場，建立一個APP管理代理。

你可以看見你的APP和其中所有的資料都存在你自己的SharePoint伺服器上，你只是使用Azure ACS用來進行APP註冊和驗證，從開發者的角度來看，你只是簡簡單單地使用了一個 client ID 和client secret, 而讓你可以無壓力或是根本不需要自義就使用 JWT libraries . 這就是為什麼我想：“低信任” 對於“高信任”來說,減少管理的複雜性真是無可比擬的優勢。4.配置高信任APP

無論你用什麼樣的技術建立APP，Visual Studio 、ASP.NET MVC running on IIS 或是 Azure Web Sites，或是使用Eclipse 或是 Tomcat （Apache and Linux），這個註冊的步驟，是完全一樣的，如下的命令必須由管理員在控制檯的介面中完成，主要的目的就是完成X.509證照的信任配置：

PowerShell for High Trust Apps
#Tell SharePoint to trust the certificate
$publicCertPath = "C:\HighTrust.cer"
$certificate = Get-PfxCertificate $publicCertPath
New-SPTrustedRootAuthority -Name "HighTrust" -Certificate $certificate
 
#Get the tenant ID.  For on-premises default installations,
#this will be the same as the SharePoint farm ID
$spweb = Get-SPWeb "https://mysite.contoso.com"
$realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site
 
#Specify the issuer ID
$issuerID = "b77a601b-3133-4567-bb37-f147f61dd332"
$fullIssuerIdentifier = $issuerId + '@' + $realm
 
#Create a trusted security token issuer based on the certificate
New-SPTrustedSecurityTokenIssuer -Name "Contoso S2S HighTrust Apps" -Certificate $certificate -RegisteredIssuerName $fullIssuerIdentifier IsTrustBroker
 
#IISRESET is needed, otherwise settings won't be applied for 24 hours
iisreset
 

完全的配置步驟，可以參考如下的文章：

“How to: Create high-trust apps for SharePoint 2013 (advanced topic)”. 這個APP將會使用證照，證照密碼和頒發的ID去得到一個ACCESS TOKEN, Visual Studio提供了這樣的工具去完成這個。

可悲呀！非微軟的程式，必須要去管理這些值，以去得到Access Token。

4. JWT Tokens

SharePoint 使用JWT tokens 來進行OAuth認證。可別讓這個英文“token” 嚇壞你這個好基友了，你就把這個東東當成非常非常非常（此處省略127字）複雜的加密方式. JWT tokens 是 JSON 物件, 這意味著它就是name-value pairs這種形式，感興趣你可以讀讀 The JWT specification draft 。

給SharePoint 的 access token 再介紹一次好了！再說一次！她就是JWT token,

如何你還想了解它，可以讀讀這個哦！ “Creating a Fiddler Extension for SharePoint 2013 App Tokens”.

上面可以看到其明文就是一對對鍵-值，它有12小時的有效期，取得後你就可以“為所欲為”哦。。。。。。具體內容如下表所示：

aud	Audience. The value is 00000003-0000-0ff1-ce00-00000000/<hostname>@*<realm>** . The hostname is the FQDN of the web application root or the host-header site collection root. The realm is the GUID that represents the SharePoint tenant.
iss	Issuer. <IssuerID>@*<realm>**. The issuer ID is obtained when you register the SPTrustedIdentityTokenIssuer. The realm is the GUID that represents the SharePoint tenant.
nbf	Not before. The Unix epoch time upon which the token started being valid.
exp	Expires. The Unix epoch time upon which the token expires.
nameid	The identifier for the user (more info below)
nii	The identity provider used to rehydrate the user. One of the values: urn:office:idp:activedirectory urn:office:idp:forms:membershipprovidername trusted:samlprovidername (as noted in Steve Peschka’s example below, this is what is actually configured as opposed to the documentation)
actortoken	The token for the application.

* 現實又是可愛的，當你安裝了SharePoint 2013，只有一個tenant ID, realm與SharePoint farm ID又一樣，可以通過PowerShell的命令：

Get -SPFarm | select ID 得到。

下面我們再搞定：actortoken. 這與outer token相反，actortoken 標識的是APP.

aud	Audience. The value is 00000003-0000-0ff1-ce00-00000000/<hostname>@*<realm>** . The hostname is the FQDN of the web application root or the host-header site collection root. The realm is the GUID that represents the SharePoint tenant.
iss	Issuer. <IssuerID>@*<realm>**. The issuer ID is obtained when you register the SPTrustedIdentityTokenIssuer. The realm is the GUID that represents the SharePoint tenant.
nbf	Not before. The Unix epoch time upon which the token started being valid.
exp	Expires. The Unix epoch time upon which the token expires.
nameid	Identifier for the app. <Client ID>@<realm>. The client ID uniquely identifies your app, this is provided by using AppRegNew.aspx or provided when registering an app in the Office Marketplace.

Inner token, outer token…太奇怪了，哥就不翻譯了，以免又錯了，看例子！我們我假定使用這些值，這樣容易理解一點，同樣我們上例中的示例值，也是一樣的：

SharePoint site	mysite.contoso.com
SharePoint realm ID	6305dc22-8cb8-4da3-8e76-8d0bbc0499a5
SPTrustedSecurityTokenIssuer issuer ID	b77a601b-3133-4567-bb37-f147f61dd332
Client ID	06d847ca-011f-4965-ac1f-5ad14740ad89

最後, 解碼TOKEN的程式碼我們使用了上例的示例值：

Sample Access Token Body
{
    aud:    00000003-0000-0ff1-ce00-000000000000/mysite.contoso.com@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,
    iss:    b77a601b-3133-4567-bb37-f147f61dd332@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,     
    nameid: s-1-5-21-3304015898-3601453682-3711364722-500,
    nii:    urn:office:idp:activedirectory,        
    nbf:    1320176785,     
    exp:    1320219985,             
    actortoken:     
    {         
        aud:        00000003-0000-0ff1-ce00-000000000000/mysite.contoso.com@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,
        iss:        b77a601b-3133-4567-bb37-f147f61dd332@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,         
        nameid:     06d847ca-011f-4965-ac1f-5ad14740ad89@6305dc22-8cb8-4da3-8e76-8d0bbc0499a5,                        
        nbf:        1320176785,         
        exp:        1320219985,                          
          trustedfordelegation: true
    }
}
 

看看你就會明白，拆開內容裡面沒有多少變數。

ACS模式的 S2S 協議號稱是標準的 OAuth 2.0 模型，你也可以參考學習下： [MS-SPS2SAUTH]: OAuth 2.0 Authentication Protocol: SharePoint Profile.

5."高信任"APP 與非微軟平臺

好吧，兄弟是我誤導你了，你如果這樣還在堅持使用“高信任”APP，有些事情我還得和你交待清楚。如果你不在微軟平臺下開發這種APP，你會發現找遍MSDN你都沒有沒有辦法找到一個不使用TokenHelper.cs，的例子。而檔案中的類，有巨長的程式碼，你根本無法把這個東東改造成非微軟的一平臺的程式碼。

TokenHelper.cs，真正的作用在於幫助你去解碼和加密Jwt TOKEN。

當你建立一個新的APP，如果你使用Visual Studio ，它會自動很容易地自動化地幫你填上所有相關的 OAuth 物件和值的什麼的。

這個類就是TokenHelper.cs，它即有方法可以讓你通過Azure ACS 來使用“低信任” apps，也有方法去實現“高信任”

Windows Identity
public static string GetS2SAccessTokenWithWindowsIdentity(
    Uri targetApplicationUri,
    WindowsIdentity identity)
{
    string realm = string.IsNullOrEmpty(Realm) ? GetRealmFromTargetUrl(targetApplicationUri) : Realm;
 
    JsonWebTokenClaim[] claims = identity != null ? GetClaimsWithWindowsIdentity(identity) : null;
 
    return GetS2SAccessTokenWithClaims(targetApplicationUri.Authority, realm, claims);
}
 

上面的方法接受一個WindowsIdentity，然後建立一個Access token。因為這個方法是接收WindowsIdentity的，它看起來不像可以被非微軟技術平臺所用，但是我們看看其中所用的這個方法：GetClaimsWithWindowsIdentity，沒有什麼特別之和呀！！！

Claims Identity
private static JsonWebTokenClaim[] GetClaimsWithWindowsIdentity(WindowsIdentity identity)
{
    JsonWebTokenClaim[] claims = new JsonWebTokenClaim[]
    {
        new JsonWebTokenClaim(NameIdentifierClaimType, identity.User.Value.ToLower()),
        new JsonWebTokenClaim("nii", "urn:office:idp:activedirectory")
    };
    return claims;
}
 

程式碼所做的，無非就是加了2個claim ,第1個叫nameid，它的值是sid，第2個叫nil, 告訴SharePoint如何去把nameid值對映到一個identity provider，在這個情況下，nil值就是“urn:office:idp:activedirectory”. 引數“nameid” 和“nii” 對SharePoint是特定的, 你可以把這2個宣告(claim)加到 the JWT token.

6.值從哪來

TokenHelper.cs 是Visual Studio生成的，如果你使用其它的平臺,你就必須改造. 值到哪裡去的問題我們上一節已經搞定,現在我們就搞定值從哪裡來的問題。

issuerid

當你建立註冊SPTrustedSecurityTokenIssuer時，issuer ID就生成了，這是 GUID 全部小寫.

Client ID

你通過 AppRegNew.aspx 註冊APP時填的或是自動生成的。

realm

訪問SharePoint 網站的如下url: “/_vti_bin/client.svc” ,在訪問的時候加上這個的HTTP head: "Authorization: Bearer ". 參考TokenHelper.cs中的方式：

Obtaining the Realm
public static string GetRealmFromTargetUrl(Uri targetApplicationUri)
{
    WebRequest request = WebRequest.Create(targetApplicationUri + "/_vti_bin/client.svc");
    request.Headers.Add("Authorization: Bearer ");
 
    try
    {
        using (request.GetResponse())
        {
        }
    }
    catch (WebException e)
    {
        if (e.Response == null)
        {
            return null;
        }
 
        string bearerResponseHeader = e.Response.Headers["WWW-Authenticate"];
        if (string.IsNullOrEmpty(bearerResponseHeader))
        {
            return null;
        }
 
        const string bearer = "Bearer realm=\"";
        int bearerIndex = bearerResponseHeader.IndexOf(bearer, StringComparison.Ordinal);
        if (bearerIndex < 0)
        {
            return null;
        }
 
        int realmIndex = bearerIndex + bearer.Length;
 
        if (bearerResponseHeader.Length >= realmIndex + 36)
        {
            string targetRealm = bearerResponseHeader.Substring(realmIndex, 36);
 
            Guid realmGuid;
 
            if (Guid.TryParse(targetRealm, out realmGuid))
            {
                return targetRealm;
            }
        }
    }
    return null;
}
 

上述程式碼很簡單，轉成你的平臺的程式碼就行了，對於O365來說，它設計就是給很多雲使用者使用的，realm對每一個雲使用者是不同的。

有點意思：如果你在“低信任”APP那節，配置了你的伺服器與O365伺服器之間的信任的話，realm的值是變化的哦。

nameid and niia

當配置“高信任” apps, MSDN 文件宣告Web Application 必須使用 Windows Authentication. 記住在你的APP和SharePoint之間唯一的安全的通訊就是JWT token在認證的頭“Bearer ”，這是通過SSl傳送的。當在TokenHelper中的程式碼使用WindowsIdentity所做的唯一事情就是得到SID，沒有別的目標。所以，唯一的理由APP的Web Application要求使用Windows 驗證方式，就是因為如何讓TokenHelper.cs使用WindowsIdentity 物件得到使用者的SID. 你可以改變TokenHelper.cs具體做法使用其它方法得到使用者的SID.

前一節 “JWT Tokens” 介紹了nameid （outer token）它的值是 SID, 從一個 WindowsIdentity 物件得到. 作為非微軟技術大拿的兄弟你怎樣去做,得到使用者的SID 呢？

1. 使用LDAP 這個模型去從Active Directory得到資訊.

一個哥們用PHP搞定他了，您可以看看： PHP - Get users SID from Active Directory via LDAP.

2. 如果這個使用者並不是AD中的怎麼辦？我們可以使用 ADFS 或是 Ping 或是其它一些 SAML provider, 我特別喜歡這個方式，你可以跟隨我的做法，這用到 FBA 、SAML claims Steve Peschka 有文章, Using SharePoint Apps with SAML and FBA Sites in SharePoint 2013,這是使用 SAML or FBA 使用者的話，這個方法怎麼寫。

Assert the user identity
private static JsonWebTokenClaim[] GetClaimsWithClaimsIdentity(
    System.Security.Principal.IPrincipal UserPrincipal,
    IdentityClaimType SamlIdentityClaimType, TokenHelper.ClaimsUserIdClaim id,
    ClaimProviderType IdentityClaimProviderType)
{
 
    //if an identity claim was not found, then exit
    if (string.IsNullOrEmpty(id.ClaimsIdClaimValue))
        return null;
 
    Hashtable claimSet = new Hashtable();
 
    //you always need nii claim, so add that
    claimSet.Add("nii", "temp");
 
    //set up the nii claim and then add the smtp or sip claim separately
    if (IdentityClaimProviderType == ClaimProviderType.SAML)
        claimSet["nii"] = "trusted:" + TrustedProviderName.ToLower();  //was urn:office:idp:trusted:, but this does not seem to align with what SPIdentityClaimMapper uses
    else
        claimSet["nii"] = "urn:office:idp:forms:" + MembershipProviderName.ToLower();
 
    //plug in UPN claim if we're using that
    if (id.ClaimsIdClaimType == CLAIMS_ID_TYPE_UPN)
        claimSet.Add("upn", id.ClaimsIdClaimValue.ToLower());
 
    //now create the JsonWebTokenClaim array
    List<JsonWebTokenClaim> claimList = new List<JsonWebTokenClaim>();
 
    foreach (string key in claimSet.Keys)
    {
        claimList.Add(new JsonWebTokenClaim(key, (string)claimSet[key]));
    }
 
    return claimList.ToArray();
}
 

上例中，它加入了 nameid 和nii 2個宣告, nameid 被對映到了 UPN, email, 或是SIP. 在文章中，它解釋也這3個屬性的詳細作用. 如何你的SharePoint 伺服器使用 FBA 或是 SAML 來宣告使用者, 這個資源對你將非常有用！最重要的是，這會加深你對“高信任”模式APP中如何使用使用者配置檔案服務的重要理解。 User Profile Service Application也很重要哦，兄弟你有興趣多多研究下面2篇吧！

SharePoint 2013 User Profile Sync for Claims Users

OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know

正因為我們的APP執行在各種不用的平臺上，甚至使用不用的驗證架構所有很難保證使用者都是使用AD的，既然SharePoint可以使用不同的使用者那麼你的程式也應該相容，不是嘛？

7. X.509證照

當你建立一個“高信任”APP，如果你使用Visual Studio ，你必須提供一個路徑去生成一個證照和證照密碼，X.509 證照用於對Access Token進行簽名。這個簽名就像Oauth2的客戶密碼(client secret)的作用一樣，在很高階別Json物件序列化成一個字串，這個字串是base64 Url編碼的，然後再應用簽名。同樣的步驟，在我們使用ACS 驗證方式時也發生，不過這時用於簽名的是client secret，所以你應該可以找到一個庫用來形成JWT token然後還能進行簽名的操作（當然是X.509）。

Visual Stdio 程式會在建立APP時，自動地引用 Microsoft.IdentityModel.Extensions. 我使用反編工具Telerik JustDecompile 反編了 Microsoft.IdentityModel.Extensions 我使用Visual Studio 2013 建立使用證照的SharePoint APP 的專案, 移除Microsoft.IdentityModel.Extensions, 新增上我自己的 Microsoft.IdentityModel.Extensions專案. 下面就 JWT token 建立和簽名再進行一點擴充套件.

步驟似乎是這樣:

JWT token 有2個部分：頭、正文. 頭指示了它的型別 (JWT) 和演算法, 正文就像我們之前說的 access token那樣之間用點分隔 “.”
頭被編碼成JSON, 編碼方式：base64UrlEncoded.
正文被編碼成JSON, 編碼方式：base64UrlEncoded.
2個base64UrlEncoded 值使用點連線 “.”
結果使用 X.509 證照，使用RSA SHA256 簽名演算法，和SHA256 數字演算法.
上一步結果繼續進行base64URLEncoded編碼
第 4 步結果排在第6步結果前, 用點連線 “.”

這有點程式碼，讓你可以理解這個過程：

Code Snippet
IDictionary<string, string> headerClaims = jwt.CreateHeaderClaims();
IDictionary<string, string> payloadClaims = jwt.CreatePayloadClaims();
                        
string encodedHeader = Base64UrlEncoder.Encode(headerClaims.EncodeToJson());
string encodedBody = Base64UrlEncoder.Encode(payloadClaims.EncodeToJson());
            
string formattedClaims = string.Format(CultureInfo.InvariantCulture, "{0}.{1}", encodedHeader, encodedBody);
string encodedSignature = this.Sign(formattedClaims, jwt.SigningCredentials);
 
return string.Format(CultureInfo.InvariantCulture, "{0}.{1}.{2}", encodedHeader, encodedBody, encodedSignature);
 

這邊的“jwt.SigningCredentials” 是什麼? 你看看 TokenHelper.cs,就知道這就是 X.509 證照. 在你的平臺上, 你需要一個密碼和私鑰去生成結果。

Code Snippet
private static readonly string ClientSigningCertificatePath = WebConfigurationManager.AppSettings.Get("ClientSigningCertificatePath");
private static readonly string ClientSigningCertificatePassword = WebConfigurationManager.AppSettings.Get("ClientSigningCertificatePassword");
private static readonly X509Certificate2 ClientCertificate = (string.IsNullOrEmpty(ClientSigningCertificatePath) || string.IsNullOrEmpty(ClientSigningCertificatePassword)) ? null : new X509Certificate2(ClientSigningCertificatePath, ClientSigningCertificatePassword);
private static readonly X509SigningCredentials SigningCredentials = (ClientCertificate == null) ? null : new X509SigningCredentials(ClientCertificate, SecurityAlgorithms.RsaSha256Signature, SecurityAlgorithms.Sha256Digest);
 

過程我們可以用圖表指示如下：

X.509 證照，在如一下地方一致：註冊token、建立APP、匯出公鑰到Sharepoint、SharePoint伺服器管理註冊SPTrustedSecurityTokenIssuer. 要讓SharePoint和非微軟技術和諧共生“high trust” 模式下, 需要對JWT token 進行正確使用理解, 正確插入2個宣告nii 和nameid, 對token 使用X.509 證照籤名。

8.其它平臺的JWT Libraries

想到提升開發效率，工具也是不可少的. 大量的JWT libraries可用. 試試看下面.

https://github.com/auth0/java-jwt – Java
https://github.com/firebase/php-jwt – A PHP JWT library
https://github.com/michaelrhanson/jwt-js – JWT implemented in JavaScript, used with Node.js

在我搞東搞西的研究的時候, 我注意到沒有針對ACS驗證方式：S2S實現的庫, 。。。。。。。

小手真疼，沒人柔柔。。。。使用“低信任” 吧，別搞那麼麻煩。

9.Office 365 APIs

Office 365, 挺好的O365 APIs，也不錯，O365 API 有強大的能力去建立Web Site、本地程式、 iOS、 Android和其它使用O365資料的應用程式，都是通過REST APIs 和標準的 OAuth. 就像前面我們解釋的“低信任” APP 很容易使用JWT library庫一樣, O365 APIs也是。

為改進驗證的方式，現使用標準的OAuth 流. 同樣 TokenHelper.cs，微軟推出了Active Directory Authentication Library (ADAL) 用來讓 JWT 使用Azure Active Directory 更方便，ADAL 庫提供很多方法，其中包括獲得 access token, 這樣就能在HTTP 頭中新增 “Authorization: Bearer “. 使用時無需要考慮X.509 證照或是修改現有的庫, 你可以配置你的APP使用 Azure Active Directory 然後呼叫 O365 API.

此文對些有很深的研究：, Call Multiple Services with One Login Prompt Using ADAL,

通過使用Azure Active Directory，完成一個APP，這個APP就是一個REST 呼叫, 很容易轉成你的平臺程式碼。

微軟的“Microsoft Open Technologies group‘ 已經建立了很多關於Active Directory Authentication Library (ADAL) 的非微軟平臺的庫：

如果 O365 上開發APP, 直接用這些個API吧，簡單地把一些ADAL示例轉成以上的平臺的APP，那是多美好的一天。