mobile - 什么 OpenID Connect 授权流程来验证移动应用程序用户？

Question

我正在构建一个与 RESTful API 交互的跨平台移动应用程序，并且我想使用 OpenID Connect 对我的用户进行身份验证。我将构建自己的 OpenID Connect 提供程序服务器。

OpenID.net声称：

OpenID Connect 允许所有类型的客户端（包括基于浏览器的 JavaScript 和本机移动应用程序）启动登录流程并接收有关登录用户身份的可验证断言。

但是，我找不到任何解释如何实际验证移动应用程序客户端的文档。

这个 StackExchange 回答清楚地表明 OpenID Connect 不支持“基于资源所有者密码的授权”流程或“客户端凭据”流程。

只剩下“授权代码”流程（通常由服务器端应用程序使用）和“隐式授权”流程（通常由客户端应用程序使用）。这两者似乎都依赖于将用户重定向到提供者的授权端点，并让提供者重定向回客户端 URL。我不明白这如何适用于移动应用程序。

任何人都可以向我解释（或者更好，指向我的教程或一些示例代码）来解释如何做到这一点？

更新

澄清一下：OpenID Connect 依赖于客户端将用户重定向到授权端点，然后提供者将用户重定向回客户端。在客户端不是 Web 应用程序的情况下，这如何工作？

Answer 1

Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.

So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.

A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.

Please also note that the use of the "Implicit Grant" flow is now highly discouraged.

Answer 2

I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.

This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).

There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.

Answer 3

Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.

https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472 The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:

1. Google will not vend any client_secret for an oAuth client that is typed "Android"
2. Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"

Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server: https://developers.google.com/identity/sign-in/android/backend-auth

This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.

Answer 4

查看github 上的MITREid 项目：

MITREid 连接

This project contains an OpenID Connect reference implementation in Java on the Spring platform, including a functioning server library, deployable server package, client (RP) library, and general utility libraries. The server can be used as an OpenID Connect Identity Provider as well as a general-purpose OAuth 2.0 Authorization Server.