原生驗證 (預覽)
適用於: 員工租用戶 外部租用戶 (深入瞭解)
Microsoft Entra 的原生驗證可讓您完全掌控行動應用程式登入體驗的設計。 不同於瀏覽器型解決方案,原生驗證可讓您建立能順暢融入應用程式介面,且引人注目的完美像素模式驗證畫面。 使用這種方法,您可以完全自訂使用者介面,包括設計元素、標誌放置和版面配置,確保一致且符合品牌形象的外觀。
依賴瀏覽器委派驗證的標準行動應用程式登入程式,通常會在驗證期間造成干擾性轉換。 使用者會暫時重新導向至系統瀏覽器進行驗證,只有在登入完成之後,才會回到應用程式。
雖然瀏覽器委派的驗證具備攻擊媒介減少和支援單一登入 (SSO) 等優點,但它能提供的 UI 自訂選項有限,使用者體驗也不裡想。
可用的驗證方法
目前,原生驗證支援兩種驗證方法的本機帳戶識別提供者:
- 使用一次性密碼 (OTP) 登入的電子郵件。
- 支援自助式密碼重設的電子郵件和密碼登入 (SSPR)。
原生驗證尚不支援同盟識別提供者,例如社交或企業身分識別。
使用原生驗證的時機
在 外部 ID 上實作行動應用程式的驗證時,您有兩個選項:
- Microsoft 託管的瀏覽器委派驗證。
- 完全自訂 SDK 型原生驗證。
您選擇的方法取決於應用程式的特定需求。 雖然每個應用程式都有唯一的驗證需求,但請記住一些常見的考量。 無論您選擇原生驗證還是瀏覽器委派的驗證,Microsoft Entra External ID 兩者都支援。
下表比較兩個驗證方法,以協助您決定應用程式的正確選項。
瀏覽器委派驗證 | 原生驗證 | |
---|---|---|
使用者驗證體驗 | 使用者會被帶到系統瀏覽器或內嵌瀏覽器進行驗證,只有在登入完成時才會重新導向回應用程式。 如果重新導向不會對終端使用者體驗造成負面影響,則建議使用這個方法。 | 使用者擁有豐富的原生行動裝置優先註冊和登入旅程,而不需要離開應用程式。 |
自訂體驗 | 受控 商標和自訂選項 可作為現成的功能。 | 這個以 API 為中心的方法提供高度自訂,在設計方面提供廣泛的彈性,以及建立量身打造互動和流程的能力。 |
適用性 | 適用於員工、B2B 和 B2C 應用程式,可用於原生應用程式、單頁應用程式和 Web 應用程式。 | 對於客戶第一方行動應用程式,當相同的實體操作授權伺服器和應用程式,而使用者將兩者視為相同的實體時。 |
即時播送工作 | 低。 開箱即用。 | 高。 開發人員會建置、擁有和維護驗證體驗。 |
維護工作 | 低。 | 高。 針對 Microsoft 版本的每一項功能,您必須更新 SDK 才能使用它。 |
安全性 | 最安全的選項。 | 安全性責任會與開發人員共同承擔,且必須遵循最佳做法。 很容易遭受網路釣魚攻擊。 |
支援的語言和架構 |
|
|
功能可用性
下表顯示瀏覽器委派和原生驗證的功能可用性。
瀏覽器委派驗證 | 原生驗證 | |
---|---|---|
使用電子郵件一次性密碼 (OTP) 註冊和登入 | ✔️ | ✔️ |
使用電子郵件和密碼註冊和登入 | ✔️ | ✔️ |
自助式密碼重設 (SSPR) | ✔️ | ✔️ |
社交識別提供者登入 | ✔️ | ❌ |
多重要素驗證與電子郵件一次性密碼 (OTP) | ✔️ | ❌ |
單一登入 (SSO) | ✔️ | ❌ |
如何使用原生驗證
您可以使用我們的原生驗證 API 或適用於 Android 和 iOS 的 Microsoft 驗證程式庫 (MSAL) SDK 來組建使用原生驗證的應用程式。 盡可能使用 MSAL 將原生驗證新增至您的應用程式。
如需原生驗證範例和教學課程的詳細資訊,請參閱下表。
語言/ 平台 |
範例程式碼指南 | 建置和整合指南 |
---|---|---|
Android (Kotlin) | • 登入使用者 | • 登入使用者 |
iOS (Swift) | • 登入使用者 | • 登入使用者 |
如果您打算在 MSAL 目前不支援的架構上建立行動應用程式,您可以使用我們的驗證 API。 如需詳細資訊,請遵循 此 API 參考文章。
相關內容
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應