As part of the exercise to see if OpenID Connect Messages 1.0 were written appropriately so that other bindings can be produced, Jun Eijima and I have created a custom scheme binding of the OpenID Connect, and implemented it on iPhone.
In the first pass, we did it in three steps (1. Registration, 2. Authorization, 3. Userinfo request) , exactly following the Standard model. However, this proved to be a user interface nightmare. In the Standard case, the registration and userinfo request/response happens server to server without a user-agent/browser involvement. Unfortunately, this is not the case for the IdP on iPhone case. All the communication has to be through Safari. Thus, all three steps stated above would involve browser dance, which is a pretty bad user experience.
In the second incarnation, we have decided to overlay the registration and the userinfo request / response over the authorization request / response. We further decided that only request by reference is supported. This has an advantage that the client can be authenticated by the TLS session.
The binding thus became like this:
1. Prepare a request parameter file
Request Object will look like:
"response_type": "token id_token userinfo",
"scope": "openid profile",
This is then captured into a file with a URL https://example.com/rp/rpf.json
Note that the client_id is not something the IdP gives out to the client, in this case. Instead, it is the fully qualified URL.
2. Make an authorization request
Next step is to make the authorization request.
It is a straight forward “request by reference” except that it uses custome scheme “openid://” instead of normal https://.
Typically, the user arrives at the web site and clicks [Login] button, which is linked to something like:
3. IdP fetches the request file
When the IdP on iPhone is invoked through the custom scheme as in section 2., the IdP obtains the URL of the request file and fetches it.
When doing so, the IdP should check the SSL certificate’s CN to the client_id.
4. User Authorizes
Assuming that the iPhone has a password lock, we can skip the authentication. (If you want, you can set a pin in the IdP application as well.) Thus, the user is shown the authorization dialogue.
5. Response Returned
In the fragment are three tokens in this case:
- access_token : Normal OAuth 2.0 access token.
- id_token: JWS signed OpenID Connect ID Token. Public key corresponding to the signing key is found in iss & user_id member.
- iss: Issuer of this token. Unlike the normal case where it is a URL, in this self issued IdP, it is the public key of the key pair that was generated for the client.
- user_id: Same as iss. Thus, if iss==user_id, the client can identify that it is a self issued IdP.
- nonce: defined in Messages.
- exp: ditto
- iat: ditto
- userinfo_token: JWT that include the userinfo JSON as the body.
Then the web server inspects id_token, and logs the user in.
6. Advantages and Issues of IdP on a smartphone
There are several advantages that IdP on a smartphone has.
- Only YOU know where you went: Unlike when using a third party IdP, only you know where you visited.
- In the phone authentication: An App inside the phone can authenticate against IdP on the phone. No network connection is needed for this.
On the other hand, there are short comings as well.
- The RP has no way of knowing if the IdP on the smart phone is installed and configured.
If there is a good way to deal with this problem, please let me know.